Re: Making Event work for Win32

On Mon, Mar 20, 2000 at 10:33:51PM +0000, [email protected] wrote:
> Basically, it looks like the necessary changes could be pretty straightforward -
> the system-specific stuff is localised in c/unix_io.c

Yes.

> (and a bit in c/signal.c - what's rsignal()?)

Does Win32 support the unix notion of signals?  My vague impression is
that signals are unix specific...?

> 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). But there are two problems there -
> first, Win32 waits on file HANDLEs are "discouraged" (I quote the
> documentation...) - you;re supposed to use asynchronous IO instead. This is a
> minor issue (until MS make it stop working :-()

When you say "asynchronous IO", do you mean threads?

> - the major one is that it
> misses the point - for Win32, we don't *want* an io watcher, we want a handle
> watcher, which watches on *any* type of Win32 waitable object (plus, probably on
> the Windows message queue). An io watcher could be a special type of handle
> watcher, which automatically translates perl files into WIn32 handles, and then
> watches the underlying handle.

Yes.  This sounds promising.

> But this boils down to the bit in Event::MakeMaker.pm - "BUT I NEED A NEW TYPE
> OF WATCHER FOR MY INTERGALACTIC INFEROMETER".

Oops!  :-)

> So, how do I go about this? I could work out how to do it from the existing
> code, but I'm too idle for that... :-) And the first looks seem to indicate that
> I need stuff in the main Event.xs code if I'm to handle it that way, which isn't
> something I want to put in lightly.

1. cp c/io.c c/handle.c
2. hack to taste (salt, pepper, curry powder, etc.)
3. add Event::handle section to Event.xs
4. post patch here

> Also, there's the question of whether adding
> a new type of event (which has no counterpart on Unix) has portability
> implications.

Adding a Win32 specific Event::handle is fine as long as Event::io works
on both Unix & Win32.  The least common denominator can be portable, but
we can also fully support both native APIs.

> But I don't want to force Win32 events to fit the Unix model, any
> more than I see the Unix model being mangled to fit the WIn32 model.
> 
> Thoughts...?

Union.  :-)

-- 
"Never ascribe to malice that which can be explained by stupidity."
                           via, but not speaking for Deutsche Bank