Forum: JRuby JRuby, fork, exec and daemons (oh my)

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Tim P. (Guest)
on 2009-05-15 03:21
(Received via mailing list)
The default setting under JRuby gives a very nice warning when fork is
used. It says that this is "dangerous" and is therefore turned off by
default.

However, Headius just put up a blog post about using FFI in JRuby to
call the system level fork and exec methods. Is this approach less
"dangerous" than the JRuby built in methods? Why exactly is fork
dangerous in JRuby?

Thanks for any insights / answers.

Blessings,
TwP

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Charles Oliver N. (Guest)
on 2009-05-15 03:37
(Received via mailing list)
Tim P. wrote:
> The default setting under JRuby gives a very nice warning when fork is
> used. It says that this is "dangerous" and is therefore turned off by
> default.
>
> However, Headius just put up a blog post about using FFI in JRuby to
> call the system level fork and exec methods. Is this approach less
> "dangerous" than the JRuby built in methods? Why exactly is fork
> dangerous in JRuby?

fork only brings across the calling thread, and since the JVM out of the
box uses multiple threads for GC, event handling, reference cleanup,
finalization, and so on, the resulting forked JVM won't live long. Only
if you do a fork + exec can you escape those issues, since you won't run
more than a tiny bit of code in the forked JVM.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Tim P. (Guest)
on 2009-05-15 04:37
(Received via mailing list)
On Thu, May 14, 2009 at 5:35 PM, Charles Oliver N.
<removed_email_address@domain.invalid> wrote:
>
> fork only brings across the calling thread, and since the JVM out of the box
> uses multiple threads for GC, event handling, reference cleanup,
> finalization, and so on, the resulting forked JVM won't live long. Only if
> you do a fork + exec can you escape those issues, since you won't run more
> than a tiny bit of code in the forked JVM.
>

I assume this same logic also applies to the system fork that would
called via FFI, correct?

TwP

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Tim P. (Guest)
on 2009-05-15 04:51
(Received via mailing list)
On Thu, May 14, 2009 at 6:37 PM, Tim P. <removed_email_address@domain.invalid> 
wrote:
>>> "dangerous" than the JRuby built in methods? Why exactly is fork
> called via FFI, correct?
>

And I just re-read the man pages on fork and pthread_atfork. Answered
my own question -- yes, calling fork via FFI only starts the calling
thread in the child process.

Thanks for the post about FFI, though. Got me thinking in some new
directions.

Blessings,
TwP

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Charles Oliver N. (Guest)
on 2009-05-15 05:17
(Received via mailing list)
Tim P. wrote:
>> I assume this same logic also applies to the system fork that would
>> called via FFI, correct?
>>
>
> And I just re-read the man pages on fork and pthread_atfork. Answered
> my own question -- yes, calling fork via FFI only starts the calling
> thread in the child process.
>
> Thanks for the post about FFI, though. Got me thinking in some new directions.

There are certainly a lot of interesting opportunities, though they
obviously will require plenty of care :)

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
This topic is locked and can not be replied to.