[C(++)] Strange problem with pthread

The system() function hands the argument command to the command interpreter sh(1). The calling process waits for the shell to finish executing the command, ignoring SIGINT and SIGQUIT, and blocking SIGCHLD.

When command B is executed with the "system()" call, it locks up until the thread with command A has finished. This makes the whole threading system useless because I could as well just execute the two commands sequentially.

#include <unistd.h>
#include <stdlib.h>
#include <sys/wait.h>
int __system(const char * cmd)
{
 pid_t pid;
 int status;
 if ((pid = fork()) == 0) {
 execl("/bin/sh", "/bin/sh", "-c", cmd, NULL);
 return -1;
 }
 else if (pid > 0) {
 waitpid(pid, &status, 0);
 return WEXITSTATUS(status);
 }
 else
 return -1;
}

pthreadmutexdestroy(&mutexTest);

Alexander Thomas1 wrote:
HP-UX 11.0
... I'm pretty certain that if I would take one of the dusty Solaris boxes out of our closet and run this code on them, I would get the same result as on all those operating systems. But that's probably not worth the effort, considering that the two first OSs from the above list are certified UNIX unless I'm mistaken.

But you're right, the man page of system() says nothing about threads, so maybe it's up to the vendor to decide how it behaves. I guess I'll just use emal's "DIY-system()" instead and see what Apple says about the bug report.

etresoft wrote:
Plus, pthreads is a fairly pitiful threading package.

From http://www.kernelthread.com/mac/osx/programming.html:
+"The pthread library, /usr/lib/libpthread.dylib (actually a symlink to libSystem.dylib) provides POSIX threads. Carbon includes a threads package for cooperatively scheduled threads (Thread Manager) and another for preemptively scheduled threads (Multiprocessing Services). Cocoa uses the NSThread class, while Java uses java.lang.Thread. All these are built using pthreads."+
So practically all threading packages in OS X are built upon a fairly pitiful threading package? That's reassuring 😉

Alexander Thomas1 wrote:
No, the code is a skeleton of the actual program. I could as well have used "echo hello" instead of "ls" to show that just any system call is blocked. The real program uses cdparanoia to rip audio CDs and then uses oggenc on the resulting WAV files, and finally vorbiscomment and vorbisgain. Yes, I could do this more efficiently and combine the source code from those 4 programs into one single program which would have optimal efficiency. But that's way too many effort for what it is.