Quote:
Originally Posted by
Corona688
Quote:
Probably the sensible default for this "TTY sharing" stuff is to simply not do the TTY sharing thing if there's no TTY.
But where would the output go instead?
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.
Quote:
Quote:
Well, yeah, but my aim with "shell threading" is mostly just to keep things from getting booted into a "subshell context" simply because they're occupying a particular position in the command.
External commands
have to be in a seperate context. There's just no other way to run them.
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...
Quote:
Even if you fork(), it's possible to share memory by other means. Memory you've created with mmap() can be shared between such processes. So just being in a subshell doesn't mean you'd have to lose access to variables. Environment variables though come preallocated so can't be shared that way without torturing your process environment in cruel and unusual ways.
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...
Quote:
Why not let the mutexes do the blocking?
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...