[PD] [devel] reentrant qlist revisited

[Miller Puckette]

Hi Krzysztof,

The "reenter" flag is supposed to protect against recursion; if a
qlist gets a recursive "rewind", "next", etc message, the reenter flag
should stop the qlist from bashing its state afterward.  It seems
I haven't got it right yet however...!  I don't have time to get into Pd
sources right now (teaching and concerts!) but will try to get this one
right in a 34.x release soon.

I hadn't realized pointers could be put in qlists.  I think that's
dangerous and don't know what to do about it.  It certainly doesn't
make sense to save a pointer to a file...

cheers
Miller


On Wed, Sep 26, 2001 at 06:01:11PM +0200, Krzysztof Czaja wrote:
> hi,
> 
> after proposing midifile<->qlist addition I thought I would check
> the recently changed qlist version.
> 
> First of all, it still gives an error while running
> 
> ... <target> next; <delay> <target> ...
> 
> sequence, if <target>'s output is connected to qlist's input.
> I am now looking at the code, and suspect that the added
> x_reentered flag-field is meant to break infinite loops,
> occuring when a qlist object is self-feeding itself with
> a 'rewind' message.
> 
> Well, reading code is misleading most of the time, so I may be
> wrong, but if not, then it is rather a `restarted' flag.
> 
> So my question is this: what about recursive `next' message?
> Can we simply say, that it should not be used?  Maybe so, but
> maybe there is even simpler solution.  What happens now is
> that:
> 
> 1. qlist_donext() in passes 1 to n of its main loop reads all
> not delayed messages up to a recursive `next';
> 
> 2. recursive `next' causes invocation of a child-call of
> qlist_donext();
> 
> 3. a child-call reads remaining messages up to a float (delay)
> and quits;
> 
> 4. in pass n+1 of the main loop of parent-call, qlist_donext()
> reuses a previous target, passing it a new target as a message
> selector -- error.
> 
> Target reusing should happen iff a new message is preceded by
> a comma -- or am I completely wrong here?  If I am right, then
> maybe instead of checking, if we are going to read a new target,
> ie. instead of using a `semicolon-flag', it would be better to
> use a `comma-flag', ie. to check, if we are going to use
> a previous target.
> 
> This change would protect from semicolon-swallowing recursion.
> 
> Btw. what is the policy about adding pointers to qlists?
> It is now possible, but 1) pointer values cannot be saved in
> a file, and 2) in the current implementation pointers act as
> `comments', ie. everything starting from the pointer and up to
> a comma or a semicolon is ignored.
> 
> Krzysztof