I've been looking at the Serial stuff, and would like to make it work
asynchronously. It can potentially generate events as fast as 800000
per second (4000000 bps, single char reads & writes), but is more likely
to generate events up to maybe 2000/second (115200 bps, 10 char reads&writes).
This is still pretty fast.

This, I believe, can't use SIGIO (which apparently has problems with HP-UX,
according to the comments in the Unix files). Why is this, BTW? Anyone
remember what the HP-UX problems were?

So I'm stuck with using select().

Now, I understand that the socket stuff uses setSocketPollFunction() to
hook the event loop. Unfortunately, this doesn't leave any room for any
other module to do the same thing. setSocketPollFunction() doesn't even
return the last poll function, which would allow for chaining.

Same thing for setSoundPollFunction().

With this model, every module that needs a poll function would have to
add to sqXWindow.c, which is clearly not a great way to go.

And there's quite a bit of asymmetry: we call the socket poll function
but not the sound poll function for delaying (in
ioRelinquishProcessorForMicroseconds).
And it's the socketPollFunction that also ends up taking an extraFD that is
checked for activity (in this case, X events). So when waiting, we don't
check for sound completion but we do check for socket activity.

But in HandleEvents, both poll functions are called (with no delay).

Plus, the declarations of the two functions are different, which makes
calling them generically difficult (what parameters would we pass?).

Perhaps we should have something like:

	typedef (void (*)(void)) pollFunction;
	int addPollFunction( pollFunction )
and	removePollFunction( pollFunction )

that would maintain a list of poll functions to call from HandleEvents().

I guess the socketPollFunction could remain special for now.

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com