emu threads aren't put into a group on Linux

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start emu on Linux
2. Run the Linux ps
3. Count the number of processes, it will be >1

What is the expected output? What do you see instead?
Expect only one process, emu.  As I said in
http://article.gmane.org/gmane.os.inferno.general/2140/match=clone+thread ,
this is a problem for running Inferno in a shell account with a background
process quota.

What version of the product are you using? On what operating system?
Inferno 20070213 (+ some local customisations) on Linux-x86 2.6.9

Please provide any additional information below.
Patch against emu/Linux/os.c attached.  It seems to work.

Original issue reported on code.google.com by darren.b...@gmail.com on 22 Mar 2007 at 7:53

Attachments:

• patch-os.c

[GoogleCodeExporter]

i'm sure there turned out to be some problem with this approach, but i can't 
find a 
note of it.  i'll have another look at the linux kernel source (as i recall 
that's 
the only way to find out all the implications of CLONE_THREAD)

Original comment by Charles....@gmail.com on 23 Mar 2007 at 8:14

• Changed state: MullingItOver

[GoogleCodeExporter]

i think everything would be fine except for cmd.c, which needs to change the 
action 
for SIGCHLD.  it can't change the action for SIGCHLD without changing it for 
all 
other threads: CLONE_THREAD demands CLONE_SIGHAND too, which requires the same 
action for all threads in the set, although they've got per-thread masks, which 
is 
just as well, since osblock needs that. for any os cmd usage, however, it's 
essential that one particular kproc (the one that runs cmdproc in 
../port/devcmd.c) 
be able to wait for the process that executes the given host command.  it 
therefore 
needs a NULL SIGCHLD handler, so that it (alone) can wait for that process.  
but it 
can't change its SIGCHLD action without changing all the others.  but if i use 
sigprocmask simply to mask SIGCHLD, that doesn't have the same effect as 
SIG_IGN: 
the zombies will mount up, so some process must wait for them, and furthermore 
if 
several os cmd operations are active at once, they'll have to get the wait data 
from 
that global zombie waiter (which looks messy for reasons i won't go into).  so 
one 
way round it is to add another flag to kproc (as was done for KPX11), that 
tells 
Linux-specific kproc in os.c to avoid CLONE_THREAD for that one type of kproc.
i suppose that might work.

Original comment by Charles....@gmail.com on 26 Mar 2007 at 11:53

[GoogleCodeExporter]

Between Linux 2.6.something/x86 and 2.6.20/amd64, the _syscallN interface seems 
to
have been removed.  So instead of the _syscallN and prototype lines above, I 
now have
the following:

#include <unistd.h>
pid_t
gettid(void)
{
        return syscall(__NR_gettid);
}

int
tkill(pid_t tid, int sig)
{
        return syscall(__NR_tkill, tid, sig);
}

Flawed as it is, I'm loving the POSIX standard more and more as I code on Linux.

Original comment by darren.b...@gmail.com on 9 May 2007 at 12:25