[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: runloop hooking
From: |
Richard Frith-Macdonald |
Subject: |
Re: runloop hooking |
Date: |
Thu, 31 Jul 2003 16:51:02 +0100 |
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.
- runloop hooking, Jeremy Bettis, 2003/07/28
- Re: runloop hooking,
Richard Frith-Macdonald <=