From: Paul Moore [mailto:[EMAIL PROTECTED]]
>
> I could probably hash up an IO watcher based on
> MsgWaitForMultipleObjects() -- assuming that I can get from a
> Perl file object to a Win32 HANDLE (I'm pretty sure I can).
Actually, this approach looks a bit more complicated than that (but it also
looks like the way it needs to go -- see below). I need to be able to wait
on *any* Win32 "synchronisation object" - not just files. So I need a way to
pass a Win32 HANDLE which may not be related to a file at all.
The Perl API is the main point here - how about
Event->io(fd => \*STDIN, cb => \&callback);
as now, with the alternative for non-file handles of
Event->io(handle => $WIN32_HANDLE, cb => \&callback);
Internally, the fd case can convert itself to a handle form transparently.
The other side of the issue that I see is that Event revolves fundamentally
around IO-ish watchers, like it or not. This is because (correct me if this
is all wrong...) the event loop waits in pe_multiplex (which is basically
implemented as pe_sys_multiplex). But pe_sys_multiplex is implemented in
unix_io.c. So I'd need a win32_io.c, even though all of this is not really
IO related...
OK, this is going to look like a bit of a hack due to the clash in models,
but I don't want to mess with the internals just to tidy up...
I'm OK up to here, but I start to get bogged down around now, trying to make
a logical distinction, which doesn't appear in the code, between "file
handles" and "waitable objects" - because there is no such distinction in
Unix. Can someone (Joshua?) help me out here? Basically, what I'm trying to
distinguish, is those parts of unix_io.c which relate to file issues, as
opposed to those (eg, pe_sys_multiplex) which relate to waiting on "waitable
objects".
As a rough example, pe_sys_fileno is file-related, pe_sys_multiplex is
wait-related, _queue_io is what? it doesn't look system-specific, etc etc.
You get the idea...
Any pointers appreciated.
Thanks,
Paul.
