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

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> Does `count' need to be in the platform-wide structure?  Not that it
> matters.

No, but putting it there avoids to define another structure at the
platform-dependent level for Win32, unless we change AL_MUTEX into a mere
generic pointer. So we have two options for AL_MUTEX:
- a platform-wide structure that also contains the fields needed by the
various ports,
- a pointer to a private structure defined by each port.

The first one allows to easily add platform-wide fields if we ever choose to
do so. But the second one is perhaps cleaner.

> I'll send a pthreads implementation soon.  But, are AL_MUTEXes only
> designed to be used (by the user) between callbacks and the main
> thread?

Primarily, but also between callbacks called by different threads (that's
possible for the Windows port). What would you like them to be used for ?

> The reason I ask is because of this in the glibc manual:
>
>    It is not safe to call mutex functions from a signal handler.  In
>    particular, calling `pthread_mutex_lock' or `pthread_mutex_unlock'
>    from a signal handler may deadlock the calling thread.

Isn't the signal machinery disabled in the pthreads version of Allegro
(except for communicating with the OS) ?

> Also, if you disable threads in the Unix port and use SIGALRM instead,
> should:
>
> (a) AL_MUTEXes do nothing (because callbacks are then "atomic", so no
> synchronisation required)
>
> (b) AL_MUTEXes do ... something else?
>
> I guess (a).

Yes, I think (a) is the best solution.

> I think you need to move AL_MUTEX out of mutex.inl.  I don't know
> where, so I'll leave it to you.

system.h ?

--
Eric Botcazou
ebotcazou@xxxxxxxxxx