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
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
