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

[Eric B. <ebo...@li...>]

> Wait.. that'd mean we'd be right back where we started.

Not quite true because callbacks would be disabled, but I agree that the
former solution would still be non symmetrical.

> So the system must automatically lock.

I agree that's the best solution. Moreover, it is actually somehow or other
mandatory if we want to ensure thread safety for timers: the system timer
callback must lock the system mutex in order for remove_timer() (which must
lock it too) to block if it is called in the middle of the callback.

> Anyway, attached is a very trashy prototype for Linux + X11 + timer
> callbacks.  It works with both pthreads and SIGALRM.  What happens is
> that if callbacks are disabled, any new callback 'events' are added to
> the queue, which is completely flushed when callbacks are reenabled. I
> don't know if that's good (what if the flushing takes too long?), but
> it was easy to code :-)

That sounds sensible to me, and the code in src/unix/usync.c could probably
form the basis of a platform-independent src/events.c that would be used by
all platforms.

I think your idea of serializing the events is the way to go, with a single
system lock to control them. But I'm not sure whether using a dedicated
thread is the best solution under Windows, so I'll first try to attach the
event manager to the timer thread. I guess this solution is not feasible
with pthreads because pthreads can't block on CVs with a timeout value (a la
select), is it ?

--
Eric Botcazou
ebo...@mu...