Re: [AD] Mini-synchronization API proposal for 4.1.x

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2002-03-25, Eric Botcazou <ebotcazou@xxxxxxxxxx> wrote:
> >
> > if mutexes do nothing then wouldn't that be a bit odd? how would that be
> > handled? (can't wait in the handler...)
> 
> That's indeed annoying. This mutex API was primarily intended to make the
> callback functions atomic when pthread timers are used
[snip]
> 
> Solution (a) would lead to clearly state this dissymmetry in the docs, but
> that would sound a bit technical.

To me, this is unacceptable, and very misleading.  IMHO, I now think
that mutexes were the wrong choice.


Alternative proposal (idea taken from Thomas' message):

Allow temporary disabling of _user_ callbacks, and during the disabled
period, delay pending callbacks by putting them in a queue.  IIRC,
this is similar to what Michael did with the SIGALRM driver.

I think this is feasible on DOS (given a finite queue so it could be
locked in memory), and should be fine on Unix+SIGALRM.

Threaded ports should be fine, too.  One possibility is for a separate
thread to wait on a condition variable, signaled when it should start
running callbacks from the queue.  If another thread needs to run a
callback, it either adds it to the queue or calls it directly.
Probably it would be better to _always_ queue.