4 ms·

Pthreads are part of the POSIX standard. Hence the "p". Then there is pipe() and probably some more similar ones.

• pjmlp 10y ago
  Then you should read what POSIX says about pthreads, regarding mandatory and optional API support, specially the implementation semantics and UB. For example, what happens to the interactions of signal handlers semantics and thread scheduling. Or what happens to the threads when the process does a fork().
  • dozzie 10y ago
    > Or what happens to the threads when the process does a fork(). You mean this? http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html http://pubs.opengroup.org/onlinepubs/009695399/functions/for... A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Granted, it's SUSv3.
    • pjmlp 10y ago
      I would advise people that lack experience writing portable UNIX code to read "Advanced Programming in the UNIX Environment" by W. Richard Stevens and Stephen A. Rago. Just to get a glimpse of what POSIX says and what each UNIX actually does. EDIT: Not talking about you, rather in general.
  • gens 10y ago
    A thread belongs to a process so, for example, whatever the "second" thread does is the same as what a process does. POSIX defines a few mechanisms for IPC. What is optional and what is mandatory in pthreads doesn't concern me as i don't even like pthreads. (will still read what you said, later) CSP stile concurrency over pipes (be they named or not), shared memory and synchronizations over it. POSIX defines mechanisms that work as expected over UNIX platforms. I wonder how many (standards compliant) programs work differently between linux, *bsd, solaris, etc.
    • pjmlp 10y ago
      > A thread belongs to a process so, for example, whatever the "second" thread does is the same as what a process does. Wrong, you can fork() and only the thread issuing the fork () call survives the fork(), for example. There are quite a few other differences. > POSIX defines mechanisms that work as expected over UNIX platforms. Not really, there are a few semantic differences and corner cases specially outside the GNU/LINUX, *BSD ones.
      • gens 10y ago
        >Wrong, you can fork() and only the thread issuing the fork () call survives the fork(), for example. Thinking about it, it makes perfect sense. Threads are processes that share the same memory space. When a thread is created (via pthread_whatever() or clone()) it starts executing some code that is practically in a $RANDOM place. So how would one go about copying the state of a process that has threads ? Freeze all the threads and copy everything ? That way the thread, that is probably doing some job at the moment, would end up being cloned without it knowing. So you would get two processes (threads are processes) that are doing exactly the same thing. Until something external changes their (internal) state, that is. Non-determinism should always be avoided if possible. This still does not say that one couldn't write portable, threaded, UNIX compliant code. Nor that those undefined behaviors from the specs would be fixable by rewriting the spec (by adding atomic fork+exec, that seems to me to be the context of this whole thing).