Re: runloop hooking

[Richard Frith-Macdonald]

On Monday, July 28, 2003, at 06:36 PM, Jeremy Bettis wrote:

> I am trying to implement a WIN32 NSRunLoop that processes events and I 
> can't
> see how I am supposed to hook into the run loop.  On Openstep I did a
> poseAsClass:[NSRunLoop class] and replaced 
> acceptInputForMode:beforeDate:
> with a method of my own.
>
> I looked to gnustep-back for wisdom and found that the win32 version 
> of back
> uses a NSTimer with an interval of 0.1 seconds!  I am not willing to do
> that!
>
> Could someone explain to me what contexts and watchers are?  It 
> appears that
> watchers are just file descriptors, and contexts just containers for 
> all the
> file handles and timers etc for a specific run loop mode.

More or less ...
Yes, a context is just a container for the information needed for a 
specific mode.

The idea of a watcher is more than a descriptor ... it's intended to 
provide a
wrapper to represent an event type,  at present there are four of these 
...
a descriptor being/becoming readable, a descriptor being/becoming 
writable, a descriptor
having out-of-band data available, and a port being/becoming readable 
(effectively
watching a set of descriptors)

> My problem is that there are too many internal things referenced to 
> totally
> replace acceptInputForMode:beforeDate: and no good place to squeeze 
> into it.
>
> humbug.  I hope you take my patch when I am done.

When I did the port of NSRunLoop to windows, it took me three full days 
...
two to research how it could be made to work, and one to do the coding 
and testing.

Windows I/O and event handling is radically different to the unix model 
:-(
I didn't actually manage to figure out how you can efficiently watch a 
descriptor
to see if an I/O operation is possible on it, but there appear to be 
two basic approaches -
1. winsock ... works very much like unix select() for sockets and 
allows a large number
of descriptors to be watched.
2. windows events ... only signals completion ... so you need to test 
to see if an I/O
operation is in progress somehow before waiting for events.  Only 
supports 64 events
per thread, so can't support large numbers of descriptors without using 
multiple threads
and solme sort of thread synchronisation etc.

While option 2 is the way to go in order to hook general windows events 
into the system,
it was obviously too much work for a quick port, so I chose the route 
which would make
a working implementation of all existing GNUstep software possible 
quickly, and would
support reasonably large scale networking servers (that being my own 
particular area
of interest).

Ideally, acceptInputForMode:beforeDate: needs rewriting for windows, 
and the watcher
needs extending so we have more types of watchers on windows.

The method would need to use one of the windows calls to wait for 
multiple events.

We would need watchers to wait for socket read/write/oob data, and for 
any of a set of sockets
being/becoming readable ... this would duplicate the existing 
functionality (though only for
up to 64 sockets).  We would also like to have watchers able to provide 
similar capabilites
for pipe and file I/O, and of course, a watcher able to wait for an 
arbitrary windows event.

With all that working, we might consider (lower priority) a way of 
having a pool of threads
able to extend the method to supporting more than 64 events, with some 
way of syncing
the threads so we can cancel all other thread waits when an event 
arrives in any one
thread.