On Mon, 30 Jul 2012 13:48:24 +0200 Lionel Cons wrote:
> On 30 July 2012 07:32, Clark WANG <dearv...@gmail.com> wrote:
> > On Mon, Jul 30, 2012 at 11:49 AM, Irek Szczesniak <iszczesn...@gmail.com>
> > wrote:
> >>
> >> On Mon, Jul 30, 2012 at 4:15 AM, Clark WANG <dearv...@gmail.com> wrote:
> >> >
> >> > 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 :)
> >
> >
> > IMO a shell is different from a common purpose programming language, though
> > I would be happy if ksh can be as powerful and stable as Perl.
> I'd be careful with that statement. A lot of working groups at CERN
> have stopped using perl because it is an unstable pile of shit.
> Today's typical usage is to run it *twice* over the same data (which
> is insane if you get more than 1PB a day) and compare the results to
> make sure the data are correct. ksh93 doesn't have this kind of
> problem.
> But I have to admit it has others, which are IMO tightly related to
> proper quality assurance.
> >> 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
> >
> >
> > That's the point. We have to wait before the feature is stable enough. But
> > adding such an immature feature to the official ksh release concerns me that
> > it may affect the stability of other parts of ksh
> namespace support has been around for a long time, hidden behind
> SHOPT_NAMESPACE. It is also implemented very straightforward so it
> never concerned me.
> > And, you (and me :) are the experienced ksh user. A normal ksh/shell user
> > may never (want to) know these cool features. And quite a lot of users will
> > still not be able to tell the differences between "$@" and "$*", [...] and
> > [[...]], [[ str == pat ]] and [[ str == "pat" ]], ...
> Or ~(E). ~(E) has itched me a lot since the technology and syntax
> would IMO be a candidate for a standard if David would get it right
> and the rules documented. The current fuzzy guess-how-its-quoted in
> ${string//~(E)pat/repl} is a big no-no. But that's a fight between me
> and David to get it straighten out.
> Thread support however would be welcome because it solves a different
> kind of problem we have with scripting languages: Lightweight (no
> processes involved) parallel processing. 5000 child processes consume
> 12GB easily while the same application with threads will barely
> consume a 1GB. That's a huge resource saver. It'll also be much faster
> in creating and destroying worker threads than worker processes. And
> they can share data internally with ease.
> And before you condemn thread support I like to hear how it is
> implemented. If it is tacked on in an unsafe manner like in perl or
> python I'll vote against it. But if it is properly designed and
> integrated I have no doubt it will become a major feature.
> >
> >> > 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.
> >
> >
> > I personally are not quite happy with the way bash (after 2.05b) is
> > evolving. Good examples are [[ =~ ]] compatibility issues and the new
> > ${var^pat} / ${var,pat} usage.
> >
> > (Chet, I'm sorry I have to say this here. :)
> /me too, Chet :)
> >>
> >> 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.
> >
> >
> > The point is most people are using ksh more like /bin/sh. Quite a lot of
> > advanced (but basic) features are never widely used. So why introduce more
> > and more new cool features which will never fully tested?
> That is more an issue with QA. There is also the option of using a
> reduced set of SHOPT options, although not recommended because it'll
> prevent portability of scripts, which is one of ksh93's great
> strengths thanks to the huge and well-chosen set of POSIX builtin
> commands (minus grep... which is *there* but not in ast-ksh. Shame on
> the responsible person! :)
responsible person replies
just found another problem with builtin grep
grep pattern
is not interruptable
this most likely would be seen by any builtin reading from stdin
recall that we feared more builtin issues w.r.t. {stdin,stdout,stderr} as well
as signals
thus our reluctance to make them default just yet
I have already used these in $INSTALLROOT/bin/.paths
PLUGIN_LIB=cmd:cmdtst # enable for test
noPLUGIN_LIB=cmd:cmdtst # disable for workaround
to allow builds to proceed around builtin problems before they can be patched
(the master build builds with the previous build)
responsible person ponders
this is a real question, not sarcasm
"QA" has been thrown about for a bit
I'm having trouble figuring out the difference between
holding a feature back => "QA"
holding a feature back => "shameful"
> As said, please wait for the design. CERN is full of IT masterminds
> and you'll see complains if they don't like it.
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
