| Re: [AD] proposal: remove XLOCK/XUNLOCK |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] proposal: remove XLOCK/XUNLOCK
- From: Milan Mimica <milan.mimica@xxxxxxxxxx>
- Date: Sun, 23 Apr 2006 18:09:02 +0200
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=HqIAixKl2x910S8qtfEn+pSvZG+woga4XX8z2ytUFVSFkYfCHxBplijgyux83YBBzoyIzRBZCyZNmDT09WbQQ7aso/5ImoxXJiY9RaSH76G5mpjg1LYNEKVuE8uaMOtzR8LfzYJkIr2L/nzsdgcDIftWmpaUpPNUKVPZLjLR2gs=
Peter Wang wrote:
Are you sure? I thought all XInitThreads did was allow you to use
XLockDisplay/XUnlockDisplay instead of some external locking mechanism.
I thought that too, but I looked at the X.org source code and every
function that needs locking locks itself with XLockDisplay/XUnlockDisplay.
I hope they didn't forget some :-)
I think your proposal is too drastic. We can switch over to
XInitThreads/XLockDisplay easily to support Mesa without dropping all
XLOCK/XUNLOCK. Could even make it a configure option to should between
pthreads locking and X locking, for those who haven't upgraded their X
servers.
Yeah, there shouldn't be any problems just to call XInitThreads for
those libs which need it and stick to pthread mutexes. We're talking
about stable version of allegro here.
--
Milan Mimica
http://sparklet.sf.net