On Tue, 11 Sep 2012 17:31:07 +0200 Cedric Blancher wrote:
> Glenn, when is the next alpha/beta due? Is there a roadmap what you
> are planning long-term for AST?
here is a short overview of long-term ast plans
its all subject to change depending on how the research/testing goes
we're sensitive to making as much as possible opt-in
so that ast code will play nice with other 3rd party code
tsast -- thread safe ast
* the plans are far-reaching so for this once we are not focusing on
binary compatibility
* the tsast code branch is separate from current { official beta alpha }
packages
* current work is limited to libast
* the research model is to design the high level api, code the complete
<header.h>, stub() in the calls, and get a clean compile, and the fill
in the stubs() with working code
* currently libast is not even compiling yet
* based on past experience it will take a good part of autumn until we
get to tsast/ksh -c 'print "hello world"'
* change all apis to support threads
* eliminate as many globals as possible
* handle=fooopen(), foouse(handle), fooclose(handle)
* __thread-ize the remaining globals
* use ast aso to protect shared data
* make __thread data as lightweight as possible
* generic syscall intercepts
* for emulation of new features not supported by the implementation
* for emulation of features not uniformly supported by the standard
* intercepts will be via
#define foocall ast_foocall
and only affect code that includes <ast.h> i.e. its opt-in
* for one thing this will allow tested standalone ast commands
to be converted to shell builtins (that may run as a thread)
with little or no change modulo converting global state data
to a handle allocated at command/builtin startup
* intercept all of the EINTR affected syscalls to properly apply
what SA_INTERRUPT should do but doesn't
* SA_INTERRUPT only works on a subset of calls, and that subset
varies wildly between unix variants and versions within a variant
* a lightweight opt-in mechanism is tested and in place
the opt-in happens by calling an ast function in the interrupt handler
the opt-in must be done on each interrupt to override the default behavior
this will allow the handler to differentiate between signals that
are a normal part of operation (e.g. SIGCHLD) vs signals that
that mean "get me to an interactive prompt" or "get me out of here"
* support the *at() api
* emulate on systems that don't have it i.e. Roland's work
* this includes sfopenat()
* intercept non-*at() pathname syscalls and use __thread ast cwd in
corresponding *at() call
* provide a thread-specific ast cwd and use that in the intercepted pathname
calls
this cwd fd is explicitly managed by the user, default AT_FDCWD
* this will allow smooth transition of tested legacy ast between uni-process
and
multi-threaded -- otherwise every legacy api would require a "thread state"
handle argument to pass around cwd fd
* support the CLOEXEC syscall variants
* accept4(), pipe2(), foo666()
* emulate on systems that don't have it
* replace spawnveg() with spawnvex()
* we contemplated using posix_spawn*() but the api is new and already missing
a bunch of features -- each new feature results in at leat 2 new function
calls
* spawnvex() turns this around and uses posix_spawn() internally where
possible
it has 6 extensible calls and can emulate things like child cwd, umask, sid
via vfork|fork/exec on systems where posix_spawn() does not
* posix_spawn() has apis to create the child proc features but no api to
examine them
ksh e.g. has a generic section of code that sets up io redirections and then
later decides between fork() and spawn() a command -- spawnvex() allows the
same setup and provides a function call to apply the child proc features
after an explicit fork()
* fix { error(ast) optget(ast) locale } apis
* this is by far the hardest part and will probably take into oct to get it
right
because it exposes the semantic disconnect between traditional posix process
global state e.g. the environment, variations of that state within a
process,
and then variations of the state between threads -- the traditional process
model is pervasive and subsequent assumptions embedded in code are hard to
identify
done so far
* ast global vs __thread state
* syscall intercepts
* spawnvex()
working on now
* optget() => opt=optopen(), optnext(opt), optclose(opt)
the rest will be "easy" after optopen() is done
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
