Is it gevent < 1.0 compatible? Is there is anyway to expect the
gevent.subprocess backported to gevent < 1.0?
I actually maintain the package "gevent_subprocess" on pipy, but it
has never be tested on windows, either run against official python
subprocess tests (there is few tests unit test coming with it though).
So I would love to have subprocess in the stable version of gevent.
A little implementation detail question: it is waiting after a process
by catching the SIGCHL signal?
With gevent 0.13.7, when starting a lots of process, if they all
terminate at the same time, you easily miss half of the SIGCHLD (you
simply don't get them). So I did something... you know... polling
(shame on me).
Following the fact that UNIX signals are not reliable by design, this
problem is expected.
Is libev does something special about that? (threads for waitpid?)
Thanks for gevent,
Regards,
fx
On Wed, May 2, 2012 at 4:13 AM, Denis Bilenko <denis.bile...@gmail.com> wrote:
> The interface is the same as stdlib's subprocess on Python 2.7.2. It
> works on Windows.
> Is there is anyway to expect the gevent.subprocess backported to gevent < 1.0?
No, because on POSIX it uses libev's child watchers and on Windows it
uses a threadpool. Neither is present in gevent 0.13, so backporting
would be very very hard.
> I actually maintain the package "gevent_subprocess" on pipy, but it
> has never be tested on windows, either run against official python
> subprocess tests (there is few tests unit test coming with it though).
> So I would love to have subprocess in the stable version of gevent.
Well, 1.0 is bound to become stable at some point :)
Is there anything that stops you from using 1.0beta now?
> A little implementation detail question: it is waiting after a process
> by catching the SIGCHL signal?
yes, that's what libev does.
> With gevent 0.13.7, when starting a lots of process, if they all
> terminate at the same time, you easily miss half of the SIGCHLD (you
> simply don't get them). So I did something... you know... polling
> (shame on me).
> Following the fact that UNIX signals are not reliable by design, this
> problem is expected.
> Is libev does something special about that? (threads for waitpid?)
>> A little implementation detail question: it is waiting after a process
>> by catching the SIGCHL signal?
> yes, that's what libev does.
>> With gevent 0.13.7, when starting a lots of process, if they all
>> terminate at the same time, you easily miss half of the SIGCHLD (you
>> simply don't get them). So I did something... you know... polling
>> (shame on me).
>> Following the fact that UNIX signals are not reliable by design, this
>> problem is expected.
>> Is libev does something special about that? (threads for waitpid?)
> Results in a: TypeError: child watchers are only available on the default
> loop
> The subprocess.Popen call is run in a greenlet that's spawned by a patched
> gevent.threadpool.ThreadPool()
How do you use thread pool ? If you use any gevent API there (directly
or through monkey patching), an event loop would be created for each
thread. Due to libev limitations only the original event loop can work
with child watchers, hence the exception.
