On Sat, Nov 24, 2007 at 01:07:53PM -0500, Uri Guttman <[EMAIL PROTECTED]> wrote:
> 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.
Yeah, note that windows also has neither local sockets nor socketpair, but
fortunately, perl emulates socketpair by creating a tcp connection (which
is of course pretty slow and a scarce resource).
> 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 don't think this belongs in EV for these reasons:
- its a pretty drastic semantics change
- perls pseudo-threads(windows fork emulation create a copy
of the whole interpreter, thats large resource wastage that shouldn't
be done lightly.
- despite your description of "no brains" (ehe :), it is far more
complicated: EV would, from C create and tear down those threads or, if its
perl threads, it would have to tear it down together with the main program,
as otherwise the program won't exit (and I found eof-detection in select
flaky on windows).
- it is an extremely rare case, and the much more prominent cases of breakage
(for example, windows can't do this on pipes either) wouldn't be helped by
that.
This would be extremely invasive, and would also require a lot of code
(where EV already has quite a lot of code specific to win32 to work
around its limitations and missing funcitonality.
So to me it clearly fails the is-it-reasonable test, especially as far
more important cases such as pipes are not covered by this and will still
not work.
> another event loop that needs proper wrapping is wx. i found that it
Well, this sounds more like a case of AnyEvent. The diea behind AnyEvent is:
1. you use AnyEvent instead of any other event toolkit in your module
2. it will adapt automatically to the event loop used
Of course, if there is no way to add your own sockets, this sucks
majorly. I can look into it, but I would of course prefer not to have xs
code in AnyEvent so its always easily installable.
Of course, the wx interface could also provide its own anyevent API
(rxvt-unicode does the same, AnyEvent doesn't support rxvt-unicode itself
but rxvt-unicode uses its hook-in mechanism to make it work), and all
problems would be solved.
> does NOT HAVE a way to add an external socket to its event loop.
While glib for example can do this, its not obvious either (the glib I/O
model is somehow modelled after the most common denominator of win32 and
posix, which is win32, and thus a bit confusing to posix users).
(Interestingly enough, one can wrap Glib around EV by simply loading the
Glib::EV module, which solves one way, but its not that efficient).
> 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.
You mean AnyEvent here. EV is as stubborn as wx or other event loops: it
needs to be in control. While it would actually be possible to use other
event loops by providing libev backends for it (after all, kqueue/epoll
etc. are also very simple "event loops"), I don't think thats the right
solution, although the idea is interesting.
If I find time, I'll have a look at the wx situation.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
