On Thu, 09 Oct 2008 09:30, Roland Mainz wrote: > Andrew Clarke wrote: > > On Thu, 09 Oct 2008 00:36, I. Szczesniak wrote: > > > On 9/29/08, David Korn <[EMAIL PROTECTED]> wrote: > > > > Subject: Re: ksh93t and version numbering (Was Re: [ast-users] > > > > ksh93t 2008-09-26 beta src) If I make a version that works with > > > > multiple threads, then it would become a new version like 'u'. > > > > > > Supporting multiple threads would be a feature which would be greatly > > > appreciated. > > > > Ummmm, that's called "pipelines" and "co-processes" isn't it? > > No, that are seperate "processes". The idea David was talking about is > to allow multiple execution threads in one process - the threads all > share the shell's global variables but have private local variables > which they can use for parallel processing. >
Heh yes, I know the real differences. However I've had success exploiting co-processes in the past, albiet with a lot of brow-knitting coping with the management of connections through the obscure <&p, >&p and associated operators. >From your next paragraph, it sounds like some real thought has been put into the idea - would that be true? Access to shared variables would be the winning benefit. Passing back a result via a pipeline is tedious. > There are some subtle semantic issues with subshells, for example that > if a subshell instance has multiple threads we _must_ call |fork()| when > entering another subshell to prevent that changes to the environment You know, I've had some problems with this avoided fork in the past. I ended up re-writing it out of existence. If I can remember what it was I'll post something. Are there any known defects regarding this? _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
