[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] XInitThreads
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Sun, 21 May 2006 07:51:05 -0700
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=j0in5K1TBwbNpdXrsOEFWOUAc7LAhpdCsNu1P8T36fafsqtxvt1qJdK8uzU2GNxYzb6t01k9BRBsNa8GasJ+PusKHuFdtxi34fl/oA3ucPINYs0stm83vLyQ6WRvuvhvzVkRteI9ulZHhxKl9ZwoMC62RarYazcjBBkOjACwjuE=
On Sunday 21 May 2006 07:27, Milan Mimica wrote:
> Are recursive calls to XLOCK/XUNLOCK valid?
Yes, Allegro's mutex's are recursive. At least in the Unix side of things:
void _unix_lock_mutex(void *handle)
{
struct my_mutex *mx = (struct my_mutex *)handle;
if (mx->owner != pthread_self()) {
pthread_mutex_lock(&mx->actual_mutex);
mx->owner = pthread_self();
}
mx->lock_count++;
}
Though I see a bug with that. Can pthread_self() ever return (pthread_t)0? My
man pages say pthread_self just returns the thread identifier. If a thread
has an identifier of 0, it would never attempt a lock. It'd need to be
changed to:
if (mx->lock_count == 0 || mx->owner != pthread_self()) {
Though still, I'd recommend moving to X's display lock functions for
XLOCK/XUNLOCK. That's what it's supposed to be, after all. I don't see the
point in an option, either. An option for improper behavior?