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

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

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

Do you mean that the mutex API is a wrong choice, or that using mutexes to
ensure thread safety is a wrong choice ?

> 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.

Ok, so basically you want a single system lock ? Something like:
  primary thread:
    int main()
    {
       ...
       al_system_lock();
       /* all callbacks are disabled */
       al_system_unlock();
       ...
    }

How do you ensure atomicity for the callbacks ? Do you require that a
al_system_lock()/al_system_unlock() pair be placed inside the user callback
function too:
  user callback (secondary thread)
    void callback(void)
    {
       ...
       al_system_lock();
       /* the primary thread blocks if it reaches al_system_lock() */
       al_system_unlock();
    }
or does any callback automatically lock the system lock ?

> 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.

Do you mean you want a dedicated thread that flushes the queue ? In order to
shield Allegro's internals from lengthy user locks ? Is that really
necessary ? I'm a little concerned because Gillius recently reported very
long wakeup times in a similar case under Win9x, where a thread waits on a
CV that is to be signaled by another thread. This would be very bad for
timers.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx