On Wed, Aug 29, 2012 at 6:44 PM, Glenn Fowler <g...@research.att.com> wrote:
>
> On Wed, 29 Aug 2012 15:55:15 +0200 Lionel Cons wrote:
>> On 29 August 2012 15:41, Glenn Fowler <g...@research.att.com> wrote:
>> >
>> > On Wed, 29 Aug 2012 15:23:25 +0200 Lionel Cons wrote:
>> >> On 29 August 2012 15:10, Glenn Fowler <g...@research.att.com> wrote:
>> >> >
>> >> > we're going to take some research leeway and investigate the
>> >> > implications of {a}
>> >> > we're not strangers to doing stuff like that (3d(1))
>> >> > and we're not strangers to having research prove us wrong
>> >
>> >> Well, if you use {a} then please remove the mamfile code which
>> >> generates libshell.so - libshell.a is sufficient to build ksh. So far
>> >> a shared library of libshell doesn't make sense until it gets actually
>> >> usable for embedding. Right now it doesn't work for that purpose and
>> >> if you pick {a} over {b} then I don't see a chance that it'll get any
>> >> better anytime soon.
>> >
>> > I'm not sure if you are pointing out problems with bootstrap build from
>> > source
>> > or libshell.so built the right way with ast nmake -- the ksh93 Mamfile has
>> > no actions for generating shared libs -- it does have the capability to set
>> > cc -c options to generate .o's suitable for use in generating a shared lib
>
>> The problem is not packaging. I was trying to make a pun on the
>> libshell API. It's just useless for anything except using it for
>> writing a shell.
>
>> The pun was: If it useless, why ship a shared library version of libshell?
>> Why?
>
>> I say that because the usage of chdir() in libshell is a pain in the
>> arse since other APIs may want to do the same (in other threads,
>> libshell just running and used in the main thread) at the same time.
>> We have that problem for example with the Gnome and KDE file selection
>> dialogue which treat the cwd as their own property. Add libshell with
>> another chdir() at the same time and you have a nice, confused
>> application which bites itself into it's own arse. Add rm to the mix
>> and the system gets bitten into its arse.
>
>> That's why I like Olga's option {b}. It is a step forward into the
>> right direction and even covers the case that someone might want to
>> use libshell in a nested way (system() and wordexp() were given as
>> examples).
>
> the theory is that although any threaded app compiled with <ast.h>
> may look like its using chdir()/fchdir() at the process global level will
> in effect be using them at the thread local level in a thread safe manner
>
> other libs could the real chdir()/fchdir() it in a global non-thread-safe
> way and not affect the state of the <ast.h.> compiled code
Grumpf... I've discussed this with Olga (who can't really partake in
the discussion because the research.att.com spam filter is on illegal
drugs) ...
... one of the *many* problems with "hidden" per-thread globals is
that resources (like a |Shell_t*| object) created by one thread are
"locked" to that thread... which means they can no longer be borrowed
or moved to another thread without adding extra code or extra API...
something which should never be neccesary for clean, thread-enabled
API.
The 2nd issues are related to proper embedding: IMO it's very
desireable to "wean" libshell off from using the global cwd and
instead use an internal directory fd. The advantage is that a
|Shell_t*| object no longer interferes with other APIs using that
global cwd and we get closer to the goal of allowing _nested_ usage of
multiple |Shell_t*| objects in the _same_ thread, for example to
implement something like |system()| without actually creating a new
process. |system()| would create a new |Shell*t| (while the previous
instance waits), execute the code and returns to the caller. We can do
that easily with option {b} ... but not with option {a}.
Also... both options are very very similar to each other... that's why
I don't understand the fierce resistance from your side to try first
{b} and switch to {a} if that doesn't work (as said... I've written
(thread-safe (only mutex needs to be added)) |*at()| emulation code
which works on all platforms).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
