I have an element which, under some circumstances, needs to flush either
the upstream (transport buffer) or downstream (frame buffer) queue (or
maybe both; still under construction!).

Flushing the downstream queue is easy:

  gst_pad_push (myelement->srcpad,
    GST_BUFFER (gst_event_new_flush ()));

And if I understand correctly, flushing the upstream one is not much more
difficult; something like this:

  GstPad *peer = gst_pad_get_peer (myelement->sink_pad);
  GstElement *src = gst_pad_get_parent (src);
  if (GST_IS_QUEUE (src)) {
    gst_element_set_state (src, GST_STATE_PAUSED);
    gst_pad_send_event (peer, gst_event_new_flush ());
    gst_element_set_state (src, GST_STATE_PLAYING);
  }

(Arguably this code shouldn't be in my element itself; instead, the element
could generate a signal which causes the main program to flush the queue,
for instance.  But for testing...)

Anyway, the problem I found is that, if the upstream queue is full and a
writer thread is blocked waiting for the queue to empty, that thread will
stay blocked forever.

It looks to me as though the gst_queue_handle_src_event() event function
which flushes the queue should also wake up the writer thread.

It's a trivial fix (see attached patch), and I've tested it successfully;
but I just want to make sure that sending events upstream as I've done
above is acceptable practice, and that the GStreamer framework in fact
intends to support this sort of thing.  Comments...?