[28] in Pthreads mailing list archive

home help back first fref pref prev next nref lref last post

No subject found in mail header

daemon@ATHENA.MIT.EDU (Christopher Provenzano)
Mon Jun 26 15:31:21 1995

To: steven dake <scd@broked.org>
Cc: pthreads@MIT.EDU
In-Reply-To: Your message of "Tue, 27 Jun 1995 06:22:34 PDT."
             <199506271322.GAA11449@broked.org> 
Date: Mon, 26 Jun 1995 14:34:51 EDT
From: Christopher Provenzano  <proven@MIT.EDU>


> Below is a typescript of a test program I wrote which encompasses a
> problem/bug/misunderstanding_by_me:) of pthreads.  The program is supposed
> to fork(), then wait() for the child process to exit.  This works fine under
> any normal unix, but building with the pthreads library appears to have
> problems.
> 
> time without pthreads = 5secs, time with pthreads = 0 seconds (more or less).
> (.31 for overhead)
> 
> The peculiar thing is, the child process appears to exit.  Why is the child
> exiting with a 1?

Probably a bug :)
> 
> Analyzing via strace reveals:
> 
> sigaction(SIGCHLD, {0x4a18, [], SA_RESTART}, NULL) = 0
> sigaction(SIGCHLD, {SIG_DFL}, {0x4a18, [CHLD], SA_RESTART}) = 0
> getpid()                                = 11366
> kill(11366, SIGCHLD)                    = 0
> sigaction(SIGCHLD, {0x4a18, [], SA_INTERRUPT|SA_NOMASK|SA_ONESHOT}, {SIG_DFL}
> ) =
>  0
> sigreturn()                             = ? (mask now [])
> 
> which shows that the parent is being sent a signal (11366 is the parents pid)
> of SIGCHLD and this is killing the child.  I don't understand the internals
> of pthreads to know what is going on, but if anyone has any information, or
> can tell me how I can implement this in a pthreads-friendly manner, I'd reall
> y
> appreciate it.

I'll look into it. One thing you can try doing is call exec() after the
fork() call. This will at least ensure that the child is in a consistant
state.

> 
> Also, while I'm on the topic :), user-set signals do not appear to be
> functioning properly for me.

Use pthread_signal() to replace the signal() call for now. This isn't POSIX
but to replace the signal syscall on some platforms will require a lot of ASM
hacking. This should be fixed in 1_70.

> 
> PS: during setup, the configure script decided that linux doesn't have alot
> of system calls that it really does (such as bind, wait, etc as it is not
> defined in syscall.h) so I hacked the config.cache file to make it think the
> proper system calls were present.  Would doing this have the above effect?
> Was hacking the config.cache the right thing to do?

I don't know what the effect will be on the pthread internals, but hacking 
config.cache is definitely the wrong thing to do in general. The configure 
script tries to determine what syscalls are available that actually trap into 
the kernel. Under linux all socket calls use the socketcall syscall and all 
wait calls use the wait4 syscall.

> [ Stuff deleted ]

CAP

home help back first fref pref prev next nref lref last post