On Tue, Mar 21, 2000 at 12:04:02PM +0000, [EMAIL PROTECTED] wrote:
> On Tue, Mar 21, 2000 at 11:51:38AM -0000, Paul Moore wrote:
> > 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);
I'd like to see:
Event->handle(handle => $WIN32_HANDLE, cb => \&callback);
On Win32, Event::io can be implemented in terms of Event::handle. Then
we get compatibility if people restrict themselves to Event::io, and the
Win32 people are happy because they can wait on low-level handle objects
with Event::handle.
> > 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...
>
> IMO, those files are mis-named. They should just be unix.c and win32.c. As
> you point out it is not only IO that differs.
Yes, Graham is correct.
--
"Never ascribe to malice that which can be explained by stupidity."
via, but not speaking for Deutsche Bank
