On Mon, Jul 30, 2012 at 4:15 AM, Clark WANG <dearv...@gmail.com> wrote: > On Fri, Jul 27, 2012 at 9:05 PM, Lionel Cons <lionelcons1...@googlemail.com> > wrote: >> >> On 27 July 2012 14:44, FELLIN, JEFFREY K (JEFF) <j...@research.att.com> >> wrote: >> > Roland, >> > Please forgive my ignorance, but I don't understand what having a >> > threaded ksh does for improving performance nor what problem a threaded ksh >> > is solving. > > > I wanted to ask the same question. :) > >> >> > >> > Can you enlighten me as to the benefits of a threaded ksh? >> >> The benefits I would see is that ksh can have multiple worker threads >> in a single process, which is far more lightweight than multiple >> processes. The threads can also share data easily without having to >> resort to files, pipes or shared memory, which are all slow and >> expensive ways to share information. That's at least the reasons why >> there are threaded versions of perl and python, and IMO a shell with >> thread support would even be more lightweight than the former two. > > > If I need to write multi-thread programs I'll choose other languages like C, > Perl or Python, which are mature and stable enough already. I don't expect a > shell to do so much and I don't expect a shell to be so complicated. Ksh has > already implemented quite a few of cool, advanced features.
If we follow that argumentation then neither Perl or Python should have thread support :) ksh93 is capable and used as foundation for very complex applications and IMO multi-thread support would be the next logical step into the right direction. It'll help ksh-based applications which have to process a lot of interconnected data very fast, without having to resort to C or Java (developing a C application is costly and Java has a high price in resources... and may be a dead end in the long run now that Oracle took over). It'll help with servers (or CGI) which process multiple steams and still have to depend on some shared data. It'll help making parallel processing in ksh scripts easier, even for admins who only have to kill one damn process (with many threads within), and not 7000 or 8000 like we have with our current ksh or non-threaded Perl scripts. IMO multi-thread support will have it's good uses. I'll support the proposal, if it technically feasible and doesn't come with huge overhead. > A good example > is the namespace support which I don't think many people will ever use. I have to disagree with that. namespace support is useful, but IMO it will take some time for it to be useable and to be used. It will certainly help if larger shell function libraries from multiple departments are used, like we do already (we use our own namespace "support" through a ksh preprocessor which adds namespace names in front of the function and variable names - which I personally dislike a bit). > In the past few month I've reported ~30 ksh bugs most of which are very > basic shell features. ... and many of them have been fixed in newer ksh versions. It'll help if you would update more often. > I believe the reason is that there are much less > people using ksh compared to other shells or languages. I think in terms of number of Linux installations you are right, but only because bash comes as default /bin/sh in Linux. But that position has recently been challenged by the dash shell because bash3 and bash4 are BUGGY as hell and have become resource hogs. ksh93 is also part of the default installation in most Linux distributions and available in all enterprise Linux versions. In terms of *USAGE* the picture looks different. Most of our Unix servers (I'm at GE Healthcare) run /usr/bin/ksh93 800000+ times a day per server for scripted data processing or core data processing (with custom builtins). That's lot of heavy usage. > I care much about > the stability of a shell language. (You can say ksh is stable but it's also > buggy.) I agree the situation could be better, but then the releases we saw in the last half year were all betas. But I think some work needs to be done with the QA of the AST and UWIN codebases. Really. But I have no plan whatsoever and no clever idea how to improve the situation. Irek _______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
