JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-1846

Kernel::fork should use forkall(2) on solaris instead of fork(2)

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Not A Bug
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Core Classes/Modules
    • Labels:
      None
    • Environment:
      Solaris
    • Number of attachments :
      0

      Description

      Kernel::fork() will probably have to use forkall() on Solaris to have the same semantics as on Linux and MacOS where all threads are copied.

      According to http://docs.sun.com/app/docs/doc/816-5137/6mba5vpjq?a=view), Solaris' fork() creates a new process with only one thread (the caller thread). This has the bad side-effect of potentially leaving locks that were held by other threads still held, and may cause deadlock if any attempt is made to acquire those locks.

        Activity

        Hide
        Daniel Berger added a comment -

        For Solaris 9 and earlier use fork1. For Solaris 10 and later use forkall.

        This is assuming Kernel::fork is supported in JRuby, and via the JNA.

        Show
        Daniel Berger added a comment - For Solaris 9 and earlier use fork1. For Solaris 10 and later use forkall. This is assuming Kernel::fork is supported in JRuby, and via the JNA.
        Hide
        MenTaLguY MenTaLguY added a comment -

        It should be noted that Kernel::fork is defined to clone only the calling thread, so simply using forkall() would result in an incompatibility with Ruby semantics.

        I'm not sure what the best answer is; in both cases some code is going to break – code working with external resources is likely to break in the forkall() case (e.g. clones of the same thread in multiple processes writing to the same file), and code holding locks is likely to deadlock as described in the fork() case.

        Show
        MenTaLguY MenTaLguY added a comment - It should be noted that Kernel::fork is defined to clone only the calling thread, so simply using forkall() would result in an incompatibility with Ruby semantics. I'm not sure what the best answer is; in both cases some code is going to break – code working with external resources is likely to break in the forkall() case (e.g. clones of the same thread in multiple processes writing to the same file), and code holding locks is likely to deadlock as described in the fork() case.
        Hide
        Thomas E Enebo added a comment -

        updating component

        Show
        Thomas E Enebo added a comment - updating component
        Hide
        Charles Oliver Nutter added a comment -

        Not a bug; Ruby's fork only forks one thread in all cases, which is the standard behavior of fork on most platforms. forkall would be nice to have, but it can be bound through FFI if anyone really needs it.

        Show
        Charles Oliver Nutter added a comment - Not a bug; Ruby's fork only forks one thread in all cases, which is the standard behavior of fork on most platforms. forkall would be nice to have, but it can be bound through FFI if anyone really needs it.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Wayne Meissner
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: