wg_parser isn't really asynchronous in nature, at least not the way I designed it, and I don't think it makes sense for it to be asynchronous. The goal was to make a synchronous API that hides the asynchronous parts of GStreamer. The synchronous API was motivated by the fact that both mfplat and wmvcore have synchronous APIs, the need to control threads with the PE/Unix split, and the fact that I think synchronous APIs are just generally easier to reason with.
I don't see how it can **not** be asynchronous when it needs at least two threads, one reading thread that pushes data and at least another one that asynchronously waits and receives the output buffers.
With the exception of the read thread, yes. But the read thread is conceptually just a hack that exists because we can't just do callbacks. The point I was trying to make is that wg_parser is synchronous (like the wmvcore sync reader, or mfplat) and not asynchronous (like the wmvcore async reader, or quartz).
That said, I see what you mean by synchronous vs asynchronous, and the issue you're getting at, so thanks for bearing with me.
However, I don't like exposing that asynchronicity to the PE side if we can avoid it, or having a different API between parsers and transforms when we don't need to. That could mean waiting in parser_request_sample() until we get wg_parser_stream_get_sample().
The disadvantage there is that we don't get any buffering on the GStreamer side, though. Maybe that's not a problem, but it's not great to get rid of either.
I still don't like the generalized "request" mechanism; I still maintain it's a lot more complicated than it seems to you. I think my preferred approach, assuming I'm considering everything, is that we'd just introduce an allocation callback which is handled like read callbacks. (Possibly it could use the same thread, and hence also turn read requests back into the gst_cbs infrastructure...)