Tiago Vignatti <[email protected]> wrote: > Hi, > > On Tue, Aug 10, 2010 at 07:28:30AM +0200, ext Peter Hutterer wrote: > > On Tue, Aug 10, 2010 at 03:05:48PM +1000, Daniel Stone wrote: > > > > > > malloc() in a signal handler ftl > > > > urgh, yes, thanks. > > ... > > > > I guess you could just have a static int copied_valuators[MAX_VALUATORS]. > > > > I thought about that but there's more cleanup needed, GPE isn't 100% > > signal-safe yet, there's at least one caller that may screw up here. > > squash one bug, two more come out of the woodworks... > > > > Either way, please ignore this patch for now, it was only exposed due to a > > new proposed change in the wacom driver and I've already put said patch > > on hold for backwards compat issues. > > FYI, myself and Fernando have already a working tree with input generation > running inside a thread: > > http://cgit.freedesktop.org/~vignatti/xserver/log/?h=inputthread > > I don't expect/want reviews yet though. Right now we're discussing the method > of communication between threads (we're using a pipe, which seems too much for > it) and some proper test stills needed (hotplug, multiple mice, display > blanking, etc). Probably we're going to rearrange the commits in a more > human-readable form before send around. > > This work would solve mostly of this SIGIO issues we have today, for instance > Daniel's argument to not use malloc()ing during signal handler would not be > valid anymore and cursor jumping when the server is in D state > (uninterruptible).
If I'm not mistaken, the situation Daniel relates has more to do with the signal handler being unaware of the routine it interrupts. Thus, if during heap memory allocation a function is preempted by a signal handler that also allocates heap memory, the allocator could get confused and possibly corrupt its own internal state. This is a symptom of a more serious problem, which is nicely depicted here: http://www.ibm.com/developerworks/linux/library/l-reent.html _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
