cc: ast-developers@research.att.com
Subject: Re: Re: [ast-developers] Some notes about thread support in ksh93...
--------
> 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.
>
> Lionel
>
I don't think that there are as many opportunities for improvements
as you might think.
One that comes to mind is that you might be able to run
elements of a pipeline in threads using shared memory instead of
a pipe and semaphores for synchronization.
However, this will not work for all pipelines and I am not
sure that the shell can tell when it is save to use it.
For exampe, with
foo | bar
it can work when foo and bar are both built-ins and when you know
that foo and bar do not run external commands.
I don't know how common this is.
However, that are many issues assocated with using threads since
may resources are shared by all threads in a process.
Issues such as child processes and stdin, stdout, and stderr, as well
as signals have to be resolved.
A more productive approach to improved performance for existing
scripts is to have an optimizer that goes through the parse tree
and replaces
foo | bar
to a shell builtin. For example,
echo $x | sed -e 's/foo/bar/g'
could be replaced by
${x//foo/bar}
eliminating the pipeline and the need to run sed.
In rewriting existing scripts, people who know ksh93 well, can
often get an order of magnitude speedup with rewrites.
David Korn
d...@research.att.com
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
