On Wed, 14 Dec 2005, Keith Packard wrote:
>
> > Quite frankly, the simplest solution by far would be that X used a real
> > thread for mouse handling (and possibly other things, but mouse screen
> > updates really do tend to be special. I don't think X uses signals for
> > anything else than mouse updates and timers, for example).
>
> Yes, this would be easy to do, except that linking in pthreads causes
> all sorts of other things to change (like most of glibc) and might cause
> some significant performance regressions. Avoiding pthreads might well
> be advisable here.
You could, if you wanted to, do something really simple:
- at X server startup, when you know what low-level painting driver you
have (so that you can verify that the mouse re-positioning is
thread-safe, even if nothing else is), you call a "setup_mouse_thread()"
function.
- setup_mouse_thread() is some horrible system-specific hack. It might
look like
void setup_mouse_thread(void)
{
#ifdef __linux__
.. use clone(.. CLONE_THREAD ..) directly to
create the idle thread ..
#endif
}
which bypasses pthread/glibc, so that the libraries never even know
that you are multi-threaded (because, from a library standpoint, you
really aren't).
That would require that you know that all your signal handling is safe and
basically doesn't use any library routines at all. But the advantage is
that you don't change _any_ other behaviour than the fact that your few
signal handlers may run in another thread.
> > That's really what it is all about. It uses SIGIO to approximate having a
> > real thread, but we all know that there's "real threading" and then
> > there's "fake threads".
>
> Yeah, sorry about that -- SunOS didn't have threads when I first hacked
> up the SIGIO solution. It shouldn't be hard to try this though.
Linux didn't either - at least not in the signal sense (you _could_ have
used just plain threads).
> The SIGIO solution does have the advantage that the sprite handling code
> is atomic wrt the rest of the X server -- it 'knows' it will never be
> preempted by other accesses to the graphics hardware.
Yes. Using threads definitely exposes race possibilities that wouldn't be
there otherwise. So the whole thread approach either requires explicit
locking or (much much preferably) hw where there are cursor X/Y position
registers that can be programmed totally independently of anything else
(ie no "index" register crap etc).
I assume/hope most modern hardware ends up being able to do the
independent cursor programming.
Of course, if you were to use the direct-rendering infrastructure to do
this, the locking inside the kernel should protect you regardless.
> > Of course, it's actually much more likely that it just makes X very very
> > flaky. For example, if X uses siglongjmp() or something like that in a
> > signal handler (which it may well do), taking a signal in the "idle
> > thread" and then longjumping into smewhere else would do some seriously
> > horribly bad things.
>
> oh, ick. No, the X server doesn't longjmp during a signal handler. In
> fact, the only setjmp/longjmp code is deep inside FreeType error
> handling stuff.
There might still be some disgusting library that does, of course..
Linus
_______________________________________________
Desktop_architects mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/desktop_architects
