Silken mouse in XFree86 4.x

SDL Development
1

If anyone wanted to know how the very nice and smooth Silken mouse in
XFree86 4.x was implemented, it’s very simple (simpler than I had
thought), but a bit complicated to implement: they turn on the SIGIO
option on the mouse device file descriptor, then handle and dispatch
mouse events right there in the asynchronous signal handler.

The dispatching part is the hardest, doing so without crashing (because
signal handlers are a touchy business) and keeping the X server
together.

I thought that this might be useful for the fbcon driver of SDL. Maybe
you could improve overall smootheness by doing this with the X stream
file descriptor also, handling some selected events (like keypresses and
mouse events) right in the signal handler.–
“We make rope.” – Rob Gingell on Sun Microsystem’s new virtual memory.

2

If anyone wanted to know how the very nice and smooth Silken mouse in
XFree86 4.x was implemented, it’s very simple (simpler than I had
thought), but a bit complicated to implement: they turn on the SIGIO
option on the mouse device file descriptor, then handle and dispatch
mouse events right there in the asynchronous signal handler.

The dispatching part is the hardest, doing so without crashing (because
signal handlers are a touchy business) and keeping the X server
together.

I thought that this might be useful for the fbcon driver of SDL. Maybe
you could improve overall smootheness by doing this with the X stream
file descriptor also, handling some selected events (like keypresses and
mouse events) right in the signal handler.

It’s an interesting thought. It might cause deadlocks in the event
handlers though, if a signal arrives in the middle of application code
protected by a critical section.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

3

It’s an interesting thought. It might cause deadlocks in the event
handlers though, if a signal arrives in the middle of application code
protected by a critical section.

you either have to use self-locking data structures, or place

#ifdef SILKMOUSE
sigprocmask(SIG_BLOCK, fie, foo);
#endif

around the dangerous stuff in the event mechanism.

4

It’s an interesting thought. It might cause deadlocks in the event
handlers though, if a signal arrives in the middle of application code
protected by a critical section.

you either have to use self-locking data structures, or place

#ifdef SILKMOUSE
sigprocmask(SIG_BLOCK, fie, foo);
#endif

around the dangerous stuff in the event mechanism.

The event mechanism isn’t the problem, it’s application code like:

handle_event()
{
SDL_LockMutex(event_lock)
handle event…
SDL_UnlockMutex(event_lock)
}

In the current code, either the events are threaded, in which case eventually
the lock succeeds, or there is a single thread handling events at a time, and
it’s still no problem. If you implement I/O handling with SIGIO, then this
code can be executed by the thread which has already locked the mutex. I
actually think this is okay with the new mutexes, which are recursive, but…

Also, signals and threads don’t mix very well. The Linux semantics of which
thread gets a signal when a signal is delivered to a process isn’t worked out
very well. Correct me if I’m wrong, but I think the signal may be delivered
to all the threads.

Stephane Peter looked at a SIGIO implementation for our port of OpenPlay
for Myth II, and decided to go with a separate network thread because of
subtle bugs in thread/signal interaction.

In short, it’s a great idea, but probably shouldn’t be mixed with SDL’s
threading support.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

5

Also, signals and threads don’t mix very well. The Linux semantics of which
thread gets a signal when a signal is delivered to a process isn’t worked out
very well. Correct me if I’m wrong, but I think the signal may be delivered
to all the threads.

I think this might be the killer. The Linux idea of giving each thread its
own pid has interesting consequences, even if it can hide behind "undefined"
posix semantics.

Stephane Peter looked at a SIGIO implementation for our port of OpenPlay
for Myth II, and decided to go with a separate network thread because of
subtle bugs in thread/signal interaction.

I wouldn’t use it for networking either (in SDL - there are other
contexts where (real-time) signals work very well for sockets).

6

Sam Lantinga wrote:

The dispatching part is the hardest, doing so without crashing (because
signal handlers are a touchy business) and keeping the X server
together.

It’s an interesting thought. It might cause deadlocks in the event
handlers though, if a signal arrives in the middle of application code
protected by a critical section.

That’s why the implementation is though. What do you mean by a “critical
section”? One as in threading code? Aren’t signals disabled during that
time or something like that? Or is it one more reason to hate threads
for me? ;-)–
“There are two major products that come out of Berkeley: LSD and Unix.
We don’t believe this to be a coincidence.” – Jeremy S. Anderson