[osol-code] Re: [ksh93-integration-discuss] Trouble with"ERROR:ctfconvert:pics/wordexp.o: Couldn't parse stab "#vla0:(0, 14)" (source file pics/wordexp.o)" ...

[Glenn Fowler]

again
show us some real numbers that point to a hotspot in the code
that exposes appreciable time/space waste and we'll address it

adding a bunch of macros and/or ifdefs "just for dynamic arrays"
is not justification enough
neither is "dynamic arrays play nice with threads"

a code review of ast/ksh vs thread safe should be comprehensive
and not piecemeal

we own all of the ast interfaces
some have threads in mind but not implemented

for example, the stak routines are handle based
if a piece of code uses a process global handle
then its only a step away from thread specific handles

we try real hard to keep the code clean
and don't plan on threadedness lousing up the design
rather we plan on threadedness playing with the design

threads and/or relying on c99 won't be resolved this month
can we stick with requests/changes to get a stable sans-thread code base?
thanks

-- Glenn Fowler -- AT&T Research, Florham Park NJ --

On Wed, 15 Nov 2006 04:04:22 +0100 Roland Mainz wrote:
> Glenn Fowler wrote:
> > On Mon, 13 Nov 2006 23:37:17 +0100 Roland Mainz wrote:
> [snip]
> > >>> no ast code uses dynamic local arrays because it is inherently non-portable <<<
> > 
> > instead, for function local storage:
> > ksh uses the sfio based stak routines

> Yes, but those are not thread-safe (yet; another problem we have to
> re-visit later... ;-( ).

> > much of the rest of ast uses local or application global sfio string streams
> > a few isolated spots use vmalloc()/vmfree()
> > 
> > if/when *real* hotspots (>=1% of time/space) due to these tactics are exposed
> > we'll examine them and consider alternatives
> > until then wholesale switchover of burned in and tested methods to a non-portable
> > untested (w.r.t. to usage withing ast) method is not worth it
> > especially so close to a commitment to stable code

> Well, one idea is to add macros (e.g. |AST_STACK_ALLOC()| and
> |AST_STACK_FREE()| ; I wrote similar macros for Mozilla.org long ago to
> improve the string handling in the gfx/ code) which wrap the various
> methods and use C99 semantics if available and other solutions
> otherwise.