Andrew Clarke wrote: [CC:'ing ksh93-integration-discuss at opensolaris.org since the original threads discussion comes from there (long ago)] > 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 <dgk at research.att.com> 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?
Yes, technically the whole design now sits in my head and we only need to implement it step my step, starting with the |sh|-->|shp| cleanup and checking which libast APIs are not threadsafe (the Sun Studio compiler have matching tools to find problems with thread race conditions). > Access to shared variables would be the > winning benefit. Passing back a result via a pipeline is tedious. Well, one usage example was to have one large array of compound variable (such as http://www.nrubsig.org/people/gisburn/work/sun/xserver_license_extractor/X-src-20071107_XW_NV_open-src_tarballs_extraced_comments20080331.cpv - which is only a small array containing compound variables) where multiple threads process the elements and doing the "private" calculations in (thread-)local variables. > > 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. The |fork()| in this case is mandatory in any case, regardless whether we would put it into ksh93 or bash. The issue is that a thread in a subshell should not be able to manipulate global resources/variables in the parent subshell if that one has more than one thread (which defeats the normal meachnisam of save/restore of variable values normally used to avoid the |fork()|). > 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? Uhm... AFIAK there shouldn't be any issues left... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
