MultiThreading and 'fork'

Discussion in 'Perl Misc' started by Naveen Reddy, Jan 25, 2004.

  1. Naveen Reddy

    Naveen Reddy Guest

    Hello all,
    From my Perl program I can spawn a parent and a child process using
    the 'fork'.
    Is this synonymous to 'multi-threading' and are the 'threads' same as
    'processes'?

    I'm trying to understand why theres a module for threads, as in, 'use
    threads', when fork lets you accomplish the mutiltasking?

    Thanks for your time,
    Reddy
    Naveen Reddy, Jan 25, 2004
    #1
    1. Advertising

  2. Naveen Reddy

    Ben Morrow Guest

    (Naveen Reddy) wrote:
    > Hello all,
    > From my Perl program I can spawn a parent and a child process using
    > the 'fork'.
    > Is this synonymous to 'multi-threading' and are the 'threads' same as
    > 'processes'?


    No. Have you read perlthrtut?

    > I'm trying to understand why theres a module for threads, as in, 'use
    > threads', when fork lets you accomplish the mutiltasking?


    Threads are lighter than processes (creating many threads consumes
    fewer resources than creating many processes), and it is possible to
    share variables among threads. In theory all data is shared, but
    perl's ithreads copy all the perl data structures when you create a
    new thread, except those that are marked shared.

    I would say that there is a good case for considering ithreads to be
    pretty much redundant with fork() and threads::shared with Sys::Mmap
    or some such, but those concepts are not portable outside unix whereas
    ithreads are.

    Ben

    --
    Joy and Woe are woven fine,
    A Clothing for the Soul divine William Blake
    Under every grief and pine 'Auguries of Innocence'
    Runs a joy with silken twine.
    Ben Morrow, Jan 25, 2004
    #2
    1. Advertising

  3. Naveen Reddy wrote:
    > Hello all,
    > From my Perl program I can spawn a parent and a child process using
    > the 'fork'.


    Well, you can spawn a child process. The parent was there to begin
    with.

    > Is this synonymous to 'multi-threading' and are the 'threads' same as
    > 'processes'?


    No. Threads share the same address space.

    >
    > I'm trying to understand why theres a module for threads, as in, 'use
    > threads', when fork lets you accomplish the mutiltasking?


    Because fork() has much higher overhead and processes have more
    difficulty passing information back and forth.

    Chris Mattern
    Chris Mattern, Jan 25, 2004
    #3
  4. In article <>, Chris Mattern <> wrote:
    :Naveen Reddy wrote:
    :> I'm trying to understand why theres a module for threads, as in, 'use
    :> threads', when fork lets you accomplish the mutiltasking?

    :Because fork() has much higher overhead and processes have more
    :difficulty passing information back and forth.

    fork() on modern Unix systems does not necessarily
    have more overhead than perl 5.8.2 ithreads .

    Many modern unix servers have hardware-supported "copy-on-write"
    semantics -- all they have to to is sweep through the existing process
    page descriptor table, set the COW bit, and copy the resulting page
    descriptor table into the new process.

    The current implimentation (5.8.2) of ithreads involves process-level
    copying of all existing perl variables that are not marked as shared.
    If one has much data at all, that procedure is going to take longer
    than the process creation overhead.

    In a multi-threaded process I was recently working on, it took
    about (roughly) 2 seconds per ithread spawned, whereas fork()'s
    take a fraction of a second each.
    --
    Will you ask your master if he wants to join my court at Camelot?!
    Walter Roberson, Jan 25, 2004
    #4
  5. [A complimentary Cc of this posting was sent to
    Chris Mattern
    <>], who wrote in article <>:
    > Because fork() has much higher overhead and processes have more
    > difficulty passing information back and forth.


    Starting from v5.8, perl (by default) does not support threads any
    more. v5.9 has no thread support at all.

    What v5.8 supports is "emulation of fork() on Win32 systems". This
    emulation layer was hacked to implement creation of a "thread +
    cloned-interpreter" pair. Creation of such a pair (via the
    fork()-emulation layer!) is (in my measurements) 2 orders of magnitude
    slower that creation of a new child process.

    Hope this helps,
    Ilya
    Ilya Zakharevich, Jan 26, 2004
    #5
  6. In article <bv1m6b$1e0t$>,
    Ilya Zakharevich <> wrote:
    :Starting from v5.8, perl (by default) does not support threads any
    :more. v5.9 has no thread support at all.

    Perhaps that needs to be qualified with "ActiveState"? Or are
    you referring to 5005 threads as compared to ithreads ??
    --
    csh is bad drugs.
    Walter Roberson, Jan 26, 2004
    #6
  7. Naveen Reddy

    Ben Morrow Guest

    -cnrc.gc.ca (Walter Roberson) wrote:
    > In article <bv1m6b$1e0t$>,
    > Ilya Zakharevich <> wrote:
    > :Starting from v5.8, perl (by default) does not support threads any
    > :more. v5.9 has no thread support at all.
    >
    > Perhaps that needs to be qualified with "ActiveState"? Or are
    > you referring to 5005 threads as compared to ithreads ??


    Of course he is. Given Ilya's previous posts of the evils of fork(),
    it is unsurprising he dislikes ithreads. I have to admit, it seems
    rather daft to attempt to reimplement in perl something which the OS
    does perfectly well; except on those OSen which don't. I have serious
    doubts that ithread creation will ever become less expensive than
    process creation on a decent unix, simply because they are essentially
    the same operation.

    Ben

    --
    Joy and Woe are woven fine,
    A Clothing for the Soul divine William Blake
    Under every grief and pine 'Auguries of Innocence'
    Runs a joy with silken twine.
    Ben Morrow, Jan 26, 2004
    #7
  8. [A complimentary Cc of this posting was sent to
    Ben Morrow
    <>], who wrote in article <bv1pns$da$>:
    > > Perhaps that needs to be qualified with "ActiveState"? Or are
    > > you referring to 5005 threads as compared to ithreads ??

    >
    > Of course he is. Given Ilya's previous posts of the evils of fork(),
    > it is unsurprising he dislikes ithreads.


    Myself, I do not see any connection between these two acts of madness.
    Introducing fork() *was* an act of madness in '70; however, today,
    when (on Unix) most problems associated with this madness are either
    already resolved, or at least well understood, most it deserves is
    just a shrug. [Of course, outside of Unix it provides enormous
    difficulties to developers, but for the purpose of simiplicity, I
    would like to keep the discussion of ithreads focused on one
    architecture only.]

    The fact that "fork() emulation on Win32" is related to fork() has
    little to do with the problem of ithreads. Consider the code to
    perform emulation as a black box. It is just a subsystem of Perl
    which does "something".

    Now somebody got a bright idea: "running this subsystem on Unix will
    give us an interpreter running in a new thread; code reuse is a good
    thing; let us just use this subsystem to create new threads."

    "BTW, a lot of people had problems with running the old model of
    threads. We care; let us remove the support for the old model, so
    people do not have these problems."

    Now we got a system which uses a microscope to pull nails. The
    microscope does not care, but the finishing is all ruined.

    > I have to admit, it seems rather daft to attempt to reimplement in
    > perl something which the OS does perfectly well; except on those
    > OSen which don't. I have serious doubts that ithread creation will
    > ever become less expensive than process creation on a decent unix,
    > simply because they are essentially the same operation.


    Are you joking? Did you read the code for fork() emulation? Did you
    run any benchmarks? The code is 2 orders of magnitude slower than
    process creation.

    Try to create 20 ithreads/sec; it may be possible on very recent
    hardware, but I think it is close to the current maximum...

    Hope this helps,
    Ilya
    Ilya Zakharevich, Jan 26, 2004
    #8
  9. Naveen Reddy

    Ben Morrow Guest

    Ilya Zakharevich <> wrote:
    > [A complimentary Cc of this posting was sent to
    > Ben Morrow
    > <>], who wrote in article <bv1pns$da$>:
    > > I have to admit, it seems rather daft to attempt to reimplement in
    > > perl something which the OS does perfectly well; except on those
    > > OSen which don't. I have serious doubts that ithread creation will
    > > ever become less expensive than process creation on a decent unix,
    > > simply because they are essentially the same operation.

    >
    > Are you joking? Did you read the code for fork() emulation? Did you
    > run any benchmarks? The code is 2 orders of magnitude slower than
    > process creation.


    I think you must have misread me. I said that not only is ithread
    creation *currently* slower than process creation, but also there are
    good reasons for thinking that on a unix system it will *always* be
    slower, no matter how much p5p optimize it; namely, that it is
    emulating in userland something already implemented perfectly well in
    the kernel.

    Ben

    --
    don't get my sympathy hanging out the 15th floor. you've changed the locks 3
    times, he still comes reeling though the door, and soon he'll get to you, teach
    you how to get to purest hell. you do it to yourself and that's what really
    hurts is you do it to yourself just you, you and noone else *
    Ben Morrow, Jan 26, 2004
    #9
  10. [A complimentary Cc of this posting was sent to
    Ben Morrow
    <>], who wrote in article <bv3tag$gv1$>:
    > > Are you joking? Did you read the code for fork() emulation? Did you
    > > run any benchmarks? The code is 2 orders of magnitude slower than
    > > process creation.


    > I think you must have misread me. I said that not only is ithread
    > creation *currently* slower than process creation, but also there are
    > good reasons for thinking that on a unix system it will *always* be
    > slower, no matter how much p5p optimize it; namely, that it is
    > emulating in userland something already implemented perfectly well in
    > the kernel.


    Still: I do not consider your disclaimer sufficient. ;-) The overhead of
    creation of a *thread* should/could be orders of magnitude smaller
    than the overhead of creation of a new process.

    However, the overhead of creation of a *new interpreter* is very large.
    And the overhead of *cloning* an interpreter (as opposed to creating a
    new one) is jet orders of magnitude larger.

    Hope this helps,
    Ilya
    Ilya Zakharevich, Jan 27, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ilia
    Replies:
    6
    Views:
    2,987
    John Saunders
    Nov 4, 2003
  2. =?Utf-8?B?U2hhcGlybw==?=

    HttpModule multithreading and request and response corelation

    =?Utf-8?B?U2hhcGlybw==?=, Dec 7, 2004, in forum: ASP .Net
    Replies:
    7
    Views:
    759
    Scott Allen
    Dec 8, 2004
  3. Lingyun Yang
    Replies:
    4
    Views:
    11,789
    Keith Dart
    Dec 16, 2004
  4. bugbear
    Replies:
    4
    Views:
    2,890
    Arne Vajhøj
    Mar 28, 2008
  5. Eric Snow

    os.fork and pty.fork

    Eric Snow, Jan 8, 2009, in forum: Python
    Replies:
    0
    Views:
    563
    Eric Snow
    Jan 8, 2009
Loading...

Share This Page