GithubHelp home page GithubHelp logo

EventMachine hooks about posix-spawn HOT 11 CLOSED

rtomayko avatar rtomayko commented on July 28, 2024
EventMachine hooks

from posix-spawn.

Comments (11)

tmm1 avatar tmm1 commented on July 28, 2024

Sounds useful. We could add this as POSIX::Spawn::DeferrableChild, but I think it might be better off in a separate em-posix-spawn gem. How big is the implementation?

from posix-spawn.

pietern avatar pietern commented on July 28, 2024

It's about 300 lines including some comments (less verbose than the original though). Spinning it off in a different gem would work, but has the maintainability problem of keeping the interfaces/functionality more or less in sync. Not sure if that is a big problem, though, since the EM implementation might more EM specific extra's to the interface down the line.

One thing I just came across is a child process that creates a child process itself, which daemonizes inheriting stdout and stderr. This leaves the those fds open, and thereby prevents the POSIX::Spawn::Child from returning to the caller. I'm taking care of that in the EM code now, using a custom signal handler. Not a related issue to the EM bindings per-se, but an example of something where a synchronized feature set would be preferable.

from posix-spawn.

tmm1 avatar tmm1 commented on July 28, 2024

Hm, I'm not sure that belongs at the spawn layer. Usually daemonizing code will call Process.setsid and close all file descriptors to prevent problems like this.

from posix-spawn.

pietern avatar pietern commented on July 28, 2024

I agree that this shouldn't belong at the spawn layer, but rather at the place where the child is reaped again. In general, daemonizing code should do setsid and/or close stdout/stderr, but sometimes it doesn't (which is why I came across this in the first place), and you're stuck on waitpid. The alternative is to shell out and redirect and/or explicitly close the descriptors, but that kind of defies the purpose of having a fast process spawner in the first place. In addition, I'd like to spawn a child knowing that it terminates or gets terminated within N seconds and not worry about edge cases.

Either way, do you think EM code should belong in this repo with/without the SIGCHLD handler?

from posix-spawn.

tmm1 avatar tmm1 commented on July 28, 2024

I'm open to bundling EM support, but also don't want to allow this gem to get bloated.

Can you gist the implementation so we can get a sense of what's involved? If it's pretty simple and straightfoward, I'm 👍 just adding it to this repo.

/cc @rtomayko, thoughts?

from posix-spawn.

tmm1 avatar tmm1 commented on July 28, 2024

I don't quite understand how you're using SIGCHLD to fix hanging on Process.wait, or to terminate children within a timeout.

from posix-spawn.

pietern avatar pietern commented on July 28, 2024

Sorry for the delay, this is the gist: https://gist.github.com/1414341

Instead of waiting for stdout/stderr to close, this assumes the child is running until the parent receives SIGCHLD. When this happens, it does a waitpid which will immediately return with any pid of an exited child (since it just received SIGCHLD), it looks up the object in a pid registry, triggers the callbacks, etc. This handler now reaps any child, so it can't be used in combination with other code that uses waitpid. For this to work it needs to explicitly loop over the list of pids in its registry and call waitpid with WNOHANG to find if a child that registered itself with this handler exited, or it should be handled by other code. It works for me right now, but this may need to be smoothed out before going public.

from posix-spawn.

pietern avatar pietern commented on July 28, 2024

I have adapted tests for the blocking POSIX::Spawn::Child to work with EM, which the class in the gist passes.

from posix-spawn.

tmm1 avatar tmm1 commented on July 28, 2024

I think a separate gem is probably the best solution. The two implementations shouldn't be too hard to keep in sync, and a separate gem will allow for a dependency on eventmachine and more explicit support for async features.

The SIGCHLD stuff in particular is extremely useful with EM, but makes little sense with the the synchronous POSIX::Spawn::Child API.

This gem was designed to execute a single process at a time as fast as possible; in an evented environment there will always be multiple concurrent children, requiring a different feature set. I'd prefer these features were maintained and versioned separately.

Thanks for working on this, it will be quite useful to have all the features of posix-spawn available from EM servers.

from posix-spawn.

dblock avatar dblock commented on July 28, 2024

There's https://github.com/paasio/em-posix-spawn, too.

from posix-spawn.

rtomayko avatar rtomayko commented on July 28, 2024

Closing as stale and https://github.com/paasio/em-posix-spawn is a thing.

from posix-spawn.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.