>>>>> "ML" == Marc Lehmann <[EMAIL PROTECTED]> writes:
>> * An io watcher for STDIN does not work (in the mentioned Windows >> environment): terminal input does not reach the program, instead >> it is propagated to the command like processor after program >> termination. ML> Windows doesn't support this operation, select (both the perl one and the ML> windows one) works only on sockets. Since the select backend is used, and ML> libev happily uses perls select, you would have to first teach windows ML> about supporting select on the console: ML> Windows itself provides no alternative mechanism to do readyness ML> notifications (its I/O model if there were any, does not support ML> non-blocking operations, but is centered around asynchronous operations, ML> and the various WaitFor functions are not generic enough). ML> Either you use sockets, or you lose, and no event library can do anything ML> about it (this becomes more complicated as windows doesn't even support ML> the notion of a shared handle space, such as fds, so the fact that perl ML> provides fileno and other unix-stuff on windows cannot hide the fact that ML> this is part of a unix emulation, and it breaks down here and in many ML> other places). i ran into this problem a while back when trying to make an async console (stdio) for stem with event.pm. i also learn that redmond in their infinite stupidity did not allow it. my solution was to 'fork' reader and writer processes (of course this is faked with threads) and a socketpair to each process shared in the main process. then select or event will work on those sockets just fine. i did get it to work but i think it has been broken for a while (i don't to winblows dev if i can help it). so an idea for EV would be to write these short processes to allow an async console. they are pretty much just a read/write loop with a socket on one side and stdin/out on the other. no brains, just good old blocking i/o with no size limits. then you can either trap a watching of STDIN/OUT on winblows and fork these off or some other way to allow them. this way we have a properly portable way to do consoles. i will have to explore EV as soon as i can and wrap stem around it. another event loop that needs proper wrapping is wx. i found that it does NOT HAVE a way to add an external socket to its event loop. only sockets created via wx can be added. both stem and poe resorted to using polled timers to check sockets which sucks horribly. there needs to be a wx (and wxperl wrapper) that allows sockets to be added. i create my own socket connections for various reasons and didn't want to use wx's api. i don't know c++ or wx's event guts (very confusing code down there) enough to code this. if marc can't do it, maybe someone else can help. it doesn't even need to be a true wx interface as long as there is EV support so we can use its common API. thanx, uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
