[28] in Pthreads mailing list archive
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