Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

> From: Keith Packard > Date: Fri, 11 Dec 2015 15:37:24 -0800 > > Keith Packard writes: > > > Mark Kettenis writes: > > > >> However, is there a reason why you didn't use the > >> PTHREAD_MUTEX_RECURSIVE mtex type that is

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

Mark Kettenis writes: > I'd say that would be overkill. The use of recursive mutexes is > somewhat controversal, which is almost certainly why they weren't part > of POSIX initially. But they were part of Unix98 and present as an > XSI extension in POSIX until they

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

Mark Kettenis writes: > It isn't odd, because PTHREAD_RECURSIVE_MUTEX_INITIALIZE isn't in the > standard. You'll have to explicitly initialize the mutex with > pthread_mutex_init() to get a recursive mutex. Sigh. That's a pain in this case; the first use of the mutex

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

> From: Keith Packard > Date: Sat, 12 Dec 2015 13:19:59 -0800 > > Mark Kettenis writes: > > > I'd say that would be overkill. The use of recursive mutexes is > > somewhat controversal, which is almost certainly why they weren't part > > of POSIX

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

> From: Keith Packard > Date: Thu, 10 Dec 2015 07:18:23 -0800 > > Mark Kettenis writes: > > > Ugh. Exporting global variables as part of the ABI is generally not > > such a good idea. Perhaps it is better to use functions to acquire > > and release

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

Mark Kettenis writes: > However, is there a reason why you didn't use the > PTHREAD_MUTEX_RECURSIVE mtex type that is standardized by POSIX? Sorry, my documentation only mentions a non-portable version of recursive mutexes. I didn't even know that recursive mutexes had

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

Keith Packard writes: > Mark Kettenis writes: > >> However, is there a reason why you didn't use the >> PTHREAD_MUTEX_RECURSIVE mtex type that is standardized by POSIX? > > Sorry, my documentation only mentions a non-portable version of > recursive

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

On Thu, Dec 10, 2015 at 11:42:36 -0800, Keith Packard wrote: > Mark Kettenis writes: > > > Ugh. Exporting global variables as part of the ABI is generally not > > such a good idea. Perhaps it is better to use functions to acquire > > and release the input mutex

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

Mark Kettenis writes: > Ugh. Exporting global variables as part of the ABI is generally not > such a good idea. Perhaps it is better to use functions to acquire > and release the input mutex instead? Yeah, it's not a performance sensitive operation, so hiding the

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

Mark Kettenis writes: > Ugh. Exporting global variables as part of the ABI is generally not > such a good idea. Perhaps it is better to use functions to acquire > and release the input mutex instead? Yeah, the mutex isn't exactly performance critical. > Also, using

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

Emil Velikov writes: >> -BOOL serverRunning = FALSE; >> +Bool serverRunning; > Deliberate change ? The declaration in the headers is still using BOOL. Oops. So many edits; I thought for a while that we'd want to use this code to make the input thread wait for the

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

On 9 December 2015 at 23:12, Keith Packard wrote: > --- a/dix/main.c > +++ b/dix/main.c > @@ -121,12 +121,9 @@ Equipment Corporation. > extern void Dispatch(void); > > #ifdef XQUARTZ > -#include > - > -BOOL serverRunning = FALSE; > +Bool serverRunning; Deliberate change ?

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

> From: Keith Packard > Date: Wed, 09 Dec 2015 16:04:08 -0800 > > >> +extern _X_EXPORT pthread_mutex_t input_mutex; > >> +extern _X_EXPORT __thread int input_mutex_count; > >> + > > Are these really meant to be exported - a wild guess will be that the > > input drivers won't