>>>>> "MP" == Moore, Paul <[EMAIL PROTECTED]> writes:
MP> To make it worse, Win32 has a different set (as far as I can see)
MP> of features for event-driven programming than Unix does. Watch a
MP> process handle for completion? Watch the GUI message queue? Watch
MP> for a change in the contents of a directory? So forcing Win32 into
MP> the Unix-modelled Event mindset (remember - I admit to
MP> understanding little of the setup here!) where you can wait on
MP> filehandles or timers and that's it seems a retrograde step.
try looking at how perl does select (4 arg) under winblows. that is
almost all event.pm needs in some ways. i have written complex event
systems with timers and queues, based totally on select. i eben think
there is a similar call under the cygwin api library.
MP> The problem with most of these cross-platform issues is generally
MP> that there are very few people who know more than one environment,
MP> and so who can design a useful "synthesised" API, as opposed to a
MP> lowest common denominator. So the end result is often based
MP> strongly on one environment, with others being forced to
MP> emulate. Perl is strongly Unix-based, so the Win32 (and other)
MP> ports are naturally pressed to emulate Unix constructs, for better
MP> or worse (witness fork()). But the "impedance mismatch" is high.
MP> Fork is not a good model on Win32 - threads are much better (where
MP> I gather threads are worse than fork for many problems on
MP> Unix). Event is a big loser here, as Win32 is event-driven from
MP> the ground up (heck, event handling came before preemptive
MP> multitasking!!) and so the model is very rich, where the Unix
MP> event model is very limited.
i won't go there, but its event system seems to be aimed at single
things rather than collections of them. find a higher level api like a
select call and work from there. that will get you a better impedence
match to the event core code.
MP> To me, Event would be a real "killer" module on Win32, but it
MP> would have to be done properly. If Perl+Event could make Win32
MP> overlapped IO, thread programming, GUI event loops, event-based
MP> Internet programming, etc etc, easy, then you could get a BIG
MP> Win32 following - people who are used to, and like, the event
MP> model, as opposed to Unix people who are just "seeing the light"
MP> as a result of Event.
anything that kills winblows is good by me! :-)
MP> But don't dismiss Win32. Event is needed more (in some sense)
MP> there than on Unix. But the Win32 Perl population is small, and
MP> the number who really know both Win32 and Unix, and who have the
MP> time to work on it is even smaller. And (IMHO) Win32 users *need*
MP> to find out about Perl, and about open source, and about
MP> co-operative development like this.
funny how winblows has a supposedly good event api but it has no real
process handling ans stuff. unix has a much better event api that you
suspect. poll/event are very powerful and do in one system call almost
all you need. i have heard of only a couple of minor features that
winblows has that would be nice on unix. but no deal breakers.
i hate to say it too, but my event based project stem, will want event
support on winblows as well. maybe in the medium future there might be
money to do that. i have to get the unix one up and sold first.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
