On Wed, 2004-02-04 at 19:26, Michael Roitzsch wrote:
> > - getting rid of AO_PROP_PAUSE: great! we should remove redundant
> > state or variables like that as it make xine programming less error
> > prone.
> I hope this does not create any new problems. Have you seen anything
No, not at all.
> > - ticket system: i think i understood the general concept and usage,
> > but not all the details behind it (specially the irrevocable cases).
> Any specific questions? Should I try to explain some details more
Maybe you could just forward me your original message explaining the
tickets, as i believe i missed it altogether. (the only thing i read so
far about the ticket system was the code itself)
> > besides, i never saw an implementation for a system like that before,
> Me not either.
cool, so you should ask for a patent ;-)
> > btw, something that occurred me, i don't know if it
> > makes sense:
> > 1) somebody call revoke(). the function is guaranteed to return
> > with no tickets granted/acquired.
> > 2) another thread call acquire() before ticket being issued again.
> > it seems that acquire would not block since ticket_revoked==0. (?)
> That's true, because during a rewire, you will first revoke the ticket
> and then call port functions like close() and open(), which should not
> block, if acquiring a ticket for whatever reason.
> You are right that this leads to problems if the frontend calls
> functions with port access and rewiring stuff concurrently. Any way
> around this? I think storing the current thread on revocation in the
> ticket and then blocking all threads but this current one on acquire
> should work.
I thought about not reseting ticket_revoked on revoke(), just leave it
as 1. issue() would then clear it. this way the acquire() above should