On Mar 20, 11:54 am, Brice Figureau <[email protected]>
wrote:
> Yes, but I don't think you run your providers on your master. puppetd on
> Jruby will be more difficult to have.

FWIW, here's an example of daemonizing a JRuby process. The
requirement is that you have to fork+exec (really posix_spawn) since
the JVM is not forkable:

http://gist.github.com/321084

> I don't think we should. I think we should indeed push patches to JRuby.
> But I fear not everything will be supported (ie fork for instance might
> be really difficult to add to JRuby).

It is unfortunately impossible to add fork, since the JVM starts up
several threads that don't carry over to the subprocess (minor things
like, oh, garbage collection...). fork+exec can work, but generally
requires C code to ensure the fork and exec are close enough together
(and bound by JNI safe points). posix_spawn works very well, however,
since it does the fork+exec stuff all in one call. I wrote the "spoon"
gem to wrap the most basic uses of the function, but it can do a lot
more than just simple spawns.

We welcome any patches. We also are willing to expose more native-like
behaviors for e.g. Kernel#exec and Kernel#spawn (1.9) to make process
launching work better.

> To specifically answer your question, maybe we could have a
> Puppet::JRuby module in which we could put our jruby stuff.
> An interesting question: how do we check we run on JRuby?

There's a few ways to check, but the easiest is probably defined?
(JRUBY_VERSION).

- Charlie

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to