Undermining XGrabKeyboard

Paulo Cesar Pereira de Andrade pcpa at mandriva.com.br
Wed Mar 5 09:58:55 PST 2008

Eirik Byrkjeflot Anonsen wrote:
> I expect most general mallocs are thread safe these days, but actually
> making malloc signal safe is a whole other matter.  I'm not sure which
> meaning of "reentrant" you meant :)
  I think :-) I wrote about a malloc that can be called on any context,
i.e. multi thread or signal handler.

> (By the way, there are more meanings to "reentrant" than those two...)

  Like a recursive malloc? (that could be fun :-)

> While it is certainly possible to make malloc signal safe (though I
> expect that will greatly increase the likelihood of it returning
> NULL), I doubt that many mallocs are designed to be signal safe.
> Depending on malloc being signal safe sounds a bit optimistic to me...
  This should be doable if "libc" has some "cheap" way to block signals
in some key points, so that malloc would always be "atomic" from the
"program" point of view.

  Otherwise, in the case of the X Server, probably the *alloc/*free wrappers
should be modified to also disable sigio, as well as the ErrorF family
functions, and maybe some others, as stdio functions also aren't always
safe to be called from signal handlers.

  The patch I commented about already has problems, because a significant
amount of the cases where the server enters an infinite loop, it already
disables sigio before doing that...

> eirik
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg


More information about the xorg mailing list