3 ms·

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. W

by 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).

by gens 10y ago

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).