Same place it would go to normally. Whatever the shell sees as FD #1.

Obviously if you're using stdout as some kind of formatted value stream, you don't want a bunch of processes writing data to it concurrently without some kind of synchronization: this is why I described a stdout sharing mechanism (separate from the /dev/tty sharing mechanism).

If somebody ran a multithreaded loop whose jobs produced newline-delimited value streams - that's a common enough formatting convention that it could just be built in to the shell. If those processes were writing out JSON or some XML schema, then it's something the user should probably be handling, by providing a program that takes those output streams and merges them into one.


Yeah, mainly by "things" I meant builtins like variable assignment or "read". Things you would do to modify the environment, in cases where it's pretty reasonable for the user to expect that it'll modify the main shell's environment...

Hm, might have to think about that one. Of course you could get around it by simply copying all the env. variables to the shell's process memory and operating on those copies of the variables - a bit wasteful but a pretty simple dodge...

Because I'm not talking about cases where threaded built-ins are blocking on some shared resource, I'm talking about them blocking on I/O, probably to a pipe as part of a larger job...

APUE chapter 12.9 explains the situation with pthreads and fork():
"Inside the child process, only one thread exists"
Of course I would be willing to bet there are some platforms or versions of platforms that got that wrong... APUE provides some coverage of different implementations to show differences but it'd take more time to tell you if it lists any for fork() in pthreads...