On Mon, Oct 17, 2016 at 07:53 +0200, Gerhard Sittig wrote:
> On Sun, Oct 16, 2016 at 19:14 +0000, Chris Dreher wrote:
> > 
> > There is one scenario I am wondering whether it is handled.  I
> > am not familiar enough with libsigrokdecode's code to know.
> > The question is when a lower-level PD has its decode_end()
> > called and that PD flushes data with calls to put(), will the
> > next higher-level PD have its decode() called before its own
> > decode_end() is called?
> The suggested send_eof() routine is modelled after the already
> existing send() routine, so that the decode_end() methods will
> get invoked in the very order in which currently decode() methods
> get invoked.  Which translates to "in most appropriate ways" for
> stacked decoders. :)  Lower layers first, pushing remaining data
> if necessary, upper layers then, and all of it before closing the
> output.

Oh, I was rather quick there.  Sorry for not reading carefully.
That's why review and communication are good. :>  Your questions
_are_ appreciated.

Yes, the suggested patch might be lacking.  It makes sure that
decode_end() gets called, where PDs can put() pending data.  But
the patch does not explicitly arrange for calling decode() again
for upper layers.  I must have looked at send_meta() for the
recursion part mentioned above, none of it is in send().

Since I'm not too familiar with how the actual _stacking_ of
decoders is done, I "somehow assumed" that output from one PD
will get sent to the next stacked PD in somewhat transparent ways
"behind the scenes".  Which is why in srd_session_send() the
stacking appears to be implicit.  Only the lower/first PD is
getting fed explicitly, "pipes" will do the rest.

Can somebody with more experience have a look?  While I go and
have some rest, before writing more nonsense.

virtually yours
Gerhard Sittig
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.

Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
sigrok-devel mailing list

Reply via email to