Differences in pthread behaviour glibc/uClibc

[Jim Blandy]

Ralf Ertzinger <uclibc at camperquake.de> writes:
> I am currently trying to get asterisk to behave on OpenWRT (a linux
> distribution running on MIPS based WLAN routers, using 2.4 series
> kernels and uClibc).
>
> I have tracked down one problem to differences in thread behaviour
> between glibc (which asterisk was developed on) and uClibc. An very
> much boiled down example program follows:
>
> ======================================
> #include <stdio.h>
> #include <pthread.h>
> #include <unistd.h>
>
> void *test(void *foo) {
>     pthread_attr_t attr;
>
>     // pthread_attr_init(&attr);
>     // pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
>
>     fprintf(stdout, "thread pid: %d\n", getpid());
>     for (;;) {
>         printf("from thread\n");
>         sleep(1);
>     }
> }
>
> main (int argc, char **argv, char **envp) {
>     pthread_t thr;
>     pthread_attr_t attr;
>
>     pthread_attr_init(&attr);
>     pthread_attr_setinheritsched(&attr, PTHREAD_INHERIT_SCHED);
>
>     fprintf(stdout, "main pid: %d\n", getpid());
>     pthread_create(&thr, &attr, &test, NULL);
>     printf("from main\n");
>     sleep(5);
>     execve("/bin/sh", argv, envp);
>     printf("post execve()\n");
>     return 1;
> }
>
> ==================================
> This program, when run on Fedora Core/glibc shows the
> following:
>
> $ ./foo
> main pid: 26327
> from main
> thread pid: 26327
> from thread
> from thread
> from thread
> from thread
> from thread
> $
>
>
>
> On the OpenWRT platform the output is:
>
> root at OpenWRT:~# ./foo /bin/sh
> main pid: 1730
> thread pid: 1732
> from thread
> from main
> from thread
> from thread
> from thread
> from thread
>
>
> BusyBox v1.00 (2006.05.22-10:01+0000) Built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> root at OpenWrt:~# from thread
> from thread
> from thread
> from thread
> [....]
>
> The "from thread" output continues until the shell spawned via execve()
> terminates. The thread created by the main program is not killed under
> uClibc when the main program executes execve(), while it is killed
> under glibc.
>
> Which behaviour is correct?

I think FC's behavior is correct here, and OpenWRT's is not.  The
POSIX 'exec' description says:

     A call to any exec function from a process with more than one
     thread shall result in all threads being terminated and the new
     executable image being loaded and executed. 

OpenWRT is clearly not doing that.

Does OpenWRT use LinuxThreads?  There, each thread is really its own
process, and I believe 'exec' doesn't properly handle killing the
other threads.