Re: [9fans] Google search of the day - Plan9

This is a discussion on Re: [9fans] Google search of the day - Plan9 ; On Thu, 14 Feb 2008 16:45:02 -0000, Douglas A. Gwyn wrote: > john@csplan9.rit.edu wrote: >> for (; >> fork(); > > In genuine UNIX(tm) systems, there is a per-user process limit, > so eventually the fork requests start failing. However, ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Re: [9fans] Google search of the day

  1. Re: [9fans] Google search of the day

    On Thu, 14 Feb 2008 16:45:02 -0000, Douglas A. Gwyn
    wrote:

    > john@csplan9.rit.edu wrote:
    >> for (;
    >> fork();

    >
    > In genuine UNIX(tm) systems, there is a per-user process limit,
    > so eventually the fork requests start failing. However, this
    > program keeps trying to fork, so if you kill off some of the
    > child processes it will spawn replacements.
    >


    That is not limited to UNIX proper. FreeBSD (and relatives, I suppose) all
    have the /etc/login.conf where one can set limits on virtually all aspects
    of user priviliges (cputime, filesize, datasize, stacksize, coredumpsize,
    memoryuse, maxproc, openfiles, sbsize, etc) for arbitrary user classes. I
    think it will be possible to kill the spawned children, because they are
    all bound to have pids larger than a certain number.

    I do not know if Linux has similar facilities. As for Plan 9, the book by
    Francisco Ballesteros mentions a piece of code worse than the above and
    points out that the only way to get rid of it would be to reboot the
    system (which is quite as funny as the "bootsplash: silent mode," by the
    way).

    ----snippet----
    /* rabbits.c */

    #include
    #include

    void
    main(int, char*[])
    {
    // just like rabbits...
    while(fork())
    ;
    exits(nil);
    }
    ----snippet----

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

  2. Re: [9fans] Google search of the day

    Children die soon in that one. This one is worse,
    even the child starts spawning and so on...

    while(1) fork();

    > ----snippet----
    > /* rabbits.c */
    >
    > #include
    > #include
    >
    > void
    > main(int, char*[])
    > {
    > // just like rabbits...
    > while(fork())
    > ;
    > exits(nil);
    > }
    > ----snippet----
    >
    > --
    > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


  3. Re: [9fans] Google search of the day

    On Thu, Feb 14, 2008 at 3:14 PM, Eris Discordia
    wrote:
    > I think it will be possible to kill the spawned children, because they are
    > all bound to have pids larger than a certain number.
    >


    not if the pids are randomized as in OpenBSD.

    iru

  4. Re: [9fans] Google search of the day

    On Thu, 14 Feb 2008 17:28:03 -0000, Fco. J. Ballesteros
    wrote:

    > Children die soon in that one. This one is worse,
    > even the child starts spawning and so on...
    >
    > while(1) fork();
    >


    I mistook your reference in the book and copy-pasted the code for the more
    benign runaway process.

    And, thanks for having written the book and made it available online. I
    could not have begun learning Plan 9 without your book.

    On Thu, 14 Feb 2008 17:51:59 -0000, Iruata Souza
    wrote:

    > not if the pids are randomized as in OpenBSD.


    Did not know that. On FreeBSD it seems like the pids tend to grow as the
    number of processes grows. Had someone known the highest pid before the
    runaway process was executed, they could have killed any process with a
    higher pid.

    On Thu, 14 Feb 2008 17:27:19 -0000, erik quanstrom
    wrote:

    > i don't see an easy systematic solution to this type of problem.


    Some sort of rate control? Say, at most 5 processes per second. Of course,
    that would also interfere with a busy webserver that spawns worker
    threads/child processes for new connections. That could be solved by
    running the webserver as a user belonging to the legitimately busy class.
    Perhaps the question is, "what, other than human discretion,
    differentiates a runaway process from a normal albeit busy one?" There is
    very little evidence to distinguish a loop striving to compute the largest
    prime number from a loop computing the factorial of 1234567890, an
    altogether more useless task :-)

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

  5. Re: [9fans] Google search of the day

    2008/2/14, Eris Discordia :
    >
    > There is
    > very little evidence to distinguish a loop striving to compute the largest
    > prime number from a loop computing the factorial of 1234567890, an
    > altogether more useless task :-)



    I would say that trying to compute THE largest prime number would be quite
    pointless.

    -Patrick Kristiansen.


  6. Re: [9fans] Google search of the day

    On Thu, 14 Feb 2008 20:30:22 -0000, Patrick Kristiansen
    wrote:

    > 2008/2/14, Eris Discordia :
    >>
    >> There is
    >> very little evidence to distinguish a loop striving to compute the
    >> largest
    >> prime number from a loop computing the factorial of 1234567890, an
    >> altogether more useless task :-)

    >
    >
    > I would say that trying to compute THE largest prime number would be
    > quite
    > pointless.
    >
    > -Patrick Kristiansen.


    These days hardly anyone is ignorant enough to not know there are
    infinitely many prime numbers. I was kidding.

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

  7. Re: [9fans] Google search of the day

    Here's what I think is the best solution: statically allocate the
    maximum number of tasks per process:

    struct JobControlBlock { /* the name my OS uses for the info field
    of a process (job) */
    Task *mainTask; /* task == thread */
    Task *jobTasks[400]; /* pointers to entry in an array of statically
    allocated tasks */
    };

    A Task runs a function; it does not continue executing at the current
    point. Returning from that function halts the task. Returning from
    the main task halts all tasks.

    Now a SpawnTask() (fork()) can only be done to create up to 400 tasks
    with the exception of the main task.


  8. Re: [9fans] Google search of the day

    On Thu, 14 Feb 2008 22:09:04 -0000, Pietro Gagliardi
    wrote:

    > Here's what I think is the best solution: statically allocate the
    > maximum number of tasks per process:
    >
    > struct JobControlBlock { /* the name my OS uses for the info field ofa
    > process (job) */
    > Task *mainTask; /* task == thread */
    > Task *jobTasks[400]; /* pointers to entry in an array of statically
    > allocated tasks */
    > };
    >
    > A Task runs a function; it does not continue executing at the current
    > point. Returning from that function halts the task. Returning from the
    > main task halts all tasks.
    >


    That parallels Microsoft NT's concept of threads (aka, lightweight
    processes):

    //ThreadProc is the "function" the thread runs
    hThread = CreateThread (&security_attributes, dwStackSize, ThreadProc,
    pParam, dwFlags, &idThread);

    Which is rather old, by the way. The same concept re-surfaced later on in
    ..NET as the Thread and ThreadPool classes in System.Threading namespace.

    Sidenote: despite the negative hype, Windows programming is jolly merry.

    > Now a SpawnTask() (fork()) can only be done to create up to 400 tasks
    > with the exception of the main task.
    >


    As Erik Quanstrom pointed out, setting a limit for the total number of
    processes/tasks/threads would create another vulnerability. That is,
    inability to create any more processes because some
    malicious/poorly-written process is consuming all the quota.

    I am wondering which magical property of the number 400 has made it
    suitable as the limit to the number of tasks. Four hundred tasks may be
    amenable on your platform but wreak havoc on somebody else's poor old PC..

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

  9. Re: [9fans] Google search of the day

    On Fri, Feb 15, 2008 at 2:51 AM, Iruata Souza wrote:
    > On Thu, Feb 14, 2008 at 3:14 PM, Eris Discordia
    > wrote:
    > > I think it will be possible to kill the spawned children, because they are
    > > all bound to have pids larger than a certain number.

    >
    > not if the pids are randomized as in OpenBSD.


    Easy to take care of in unix, just don't kill anything until you've
    suspended all the fork happy procs. Is there a fork analog in plan 9?

    -sqweek, who should just read proc(3) but since he's commenting anyway...

  10. Re: [9fans] Google search of the day

    sqweek wrote:
    > Is there a fork analog in plan 9?


    rfork, which is more general in that the program can specify
    in more detail which resources are to be shared and which are
    to be copied.

  11. Re: [9fans] Google search of the day

    On Feb 18, 2008 10:48 AM, Douglas A. Gwyn wrote:
    > sqweek wrote:
    > > Is there a fork analog in plan 9?

    >
    > rfork, which is more general in that the program can specify
    > in more detail which resources are to be shared and which are
    > to be copied.
    >


    Or even better, fork(2) which is a library function enveloping rfork(2):

    int
    fork(void)
    {
    return rfork(RFPROC|RFFDG|RFREND);
    }

    --
    - curiosity sKilled the cat

  12. Re: [9fans] Google search of the day

    On Feb 18, 2008 6:48 PM, Douglas A. Gwyn wrote:
    > sqweek wrote:
    > > Is there a fork analog in plan 9?

    >
    > rfork, which is more general in that the program can specify
    > in more detail which resources are to be shared and which are
    > to be copied.


    Er, right. I knew that, I meant to ask if there was a SIGSTOP analog.
    I've since glanced at proc(3) which told me "echo stop >/proc/XXXX/ctl".
    -sqweek

+ Reply to Thread