Tim Rowledge wrote:

> The disadvantage is that you still have to modify the sqXWindow.c to add the
> call to the function; some time ago there was some discussion about how to
> register functions for this stuff, but since sockets and sound (the two
> current usages) require quite different arguments it seemed to be a bit
> tricky. I guess it might be useful to have the general registry you suggest
> for most cases and perhaps accept that sockets can't work that way.

Well, if we want:
	* asynch file operations
	* event-driven serial I/O

we'll have to come up with something a little more general.

We have three general patterns here:

(1) we are waiting for I/O to complete.

Under Unix, we can use SIGIO or
select(). There is an additional complication that under Unix, socket handles
and/or file handles can be mixed in select calls.

Unfortunately, under Win32, select only works on sockets, and there's
a different API for async file I/O. However, as I recall, you can get
callbacks when I/O completes.

My main concern is ioRelinquishProcessor, which has to sleep for a while.
It obviously would be better if this could be waken up by socket or other
I/O activity.

The current function
void aioPollForIO(int microSeconds, int extraFd)
can be passed only a single extra file descriptor; this doesn't allow us
to break out of the delay when, say, serial I/O happens. The extra Fd is,
as I recall, being used for X communications.

I would prefer the ability to register a file handle (and/or socket) for
monitoring
and callback when I/O completes. This could be made transparent from the
plugin's point of view. And it would allow Unix to use a single select()
call for everything (though select calls with no timeouts are fine).

Some time ago Lex Spoon suggested:
----
How about doing it this way.  The sleep routine is in the *main* part of
the Unix VM, and the socket routines can register file descriptors that
should interrupt the sleep.  Basically, make the socket sleep routine
more generic and move it out of the sockets plugin.

The main difficulty is that when you load the sockets plugin, the
sockets plugin needs to be able to access the fd-registration functions
over in the main VM.  I dunno exactly how the plugins stuff works; would
it be okay for a plugin to just directly call functions in the main VM,
or do we need to pass those functions as parameters?  If the latter, is
there space in the initializeModule() routine for adding the backpointer
to those functions?!

Note, by the way, that other plugins might want to register file
descriptors like this, as well.  For example, the sound module should
really work this way.  So it's not just a bad feeling that many of us
get about giving the sockets plugin special treatment--it can cause real
trouble down the line.
----

(2) we need an arbitrary callback into a plugin for some reason.

For instance, if some kind of periodic checking was needed. Some hardware
support (bare hardware or dumb drivers) may require this.

Again, a different kind of registration would work; this would be passed
a void* and then just call the registered functions in the main loop, passing
them back their void*.

(3) plugins need to hook X events

Bert's suggestion:

Or, we could invent a general callback list
where plugins could hook into the main loop (and startup/shutdown
functions). Something like

        struct {
                int (*init)(Display*, Window);
                int (*handle)(XEvent*);
                int (*shutdown)();
        } hooks[];


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