On Fri, 27 Jul 2012 17:36:00 +0200 Roland Mainz wrote:
> On Fri, Jul 27, 2012 at 5:26 PM, Glenn Fowler <g...@research.att.com> wrote:
> >
> > On Fri, 27 Jul 2012 16:43:37 +0200 Roland Mainz wrote:
> >> On Fri, Jul 27, 2012 at 3:23 PM, Glenn Fowler <g...@research.att.com>
> >> wrote:
> >> > On Fri, 27 Jul 2012 15:07:47 +0200 Lionel Cons wrote:
> >> >> On 27 July 2012 07:13, Roland Mainz <roland.ma...@nrubsig.org> wrote:
> >> >> > Attached (as "astksh_builtin_poll20120725_001.diff.txt") is the
> >> >> > _prototype_ patch for a poll(1) builtin and a demo application
> >> >> > (attached as "shircbot.sh.txt") which shows it's usage.
> >> >> >
> >> >> > Basic usage example:
> >> >> > -- snip --
> >> >> > $ ksh -c 'builtin poll ; function l { compound -a pl=( fd=0
> >> >> > events="POLLIN" ) ; poll pl ; print -v pl ; } ; l '
> >> >> > <enter a character>
> >> >> > (
> >> >> > (
> >> >> > events=POLLIN
> >> >> > fd=0
> >> >> > revents=POLLIN
> >> >> > )
> >> >> > )
> >> >> > -- snip --
> >> >> >
> >> >> > See output of $ poll --man # for usage and
> >> >> > https://mailman.research.att.com/pipermail/ast-developers/2012q3/001585.html
> >> >> > for further comments...
> >> >> >
> >> >> > Changes since the last version:
> >> >> > - Associative arrays now work. I've added a basic workaround for the
> >> >> > issue that walking an associative compound variable array using the
> >> >> > |nv*()|-API and then adding compound variable members to an existing
> >> >> > compound variable array element adds a new [0] element... which
> >> >> > screwed-up builtin internals. The "workaround" is to remember the
> >> >> > array subscripts and use these to write into the compound variable
> >> >> > array instead of doing this while walking the array using the
> >> >> > |nv*()|-API.
> >> >> > - "shircbot.sh" has been updated to use an associative array for
> >> >> > poll(1) data
> >> >> > - tty raw/cooked handling now uses the correct fd numbers. There is
> >> >> > still the issues that this doesn't really work with multiple different
> >> >> > ttys because the underlying |tty_raw()|/|tty_cooked()| API is not
> >> >> > designed for that.
> >> >> > - Some error handling has been fixed. The code is still so ugly that
> >> >> > little kitten will get blind and implode.
> >> >> >
> >> >> > ToDo:
> >> >> > - Fix usage of |sfpoll()| ... IMO it should only be called _once_ per
> >> >> > poll(1) call (poll(2) still needs to be called to listen for
> >> >> > POLLHUP&co.)
> >> >> >
> >> >> > - POSIX-like shell mode (e.g. add API which makes it possible that
> >> >> > poll(1) can be implemented by dash(1) or bash(1) or other shells which
> >> >> > do not have compound variables):
> >> >> > 1. If the input variable is a plain string array (not compound
> >> >> > variable array) it should read those strings and append/replace
> >> >> > "revents='...'" to those strings (this is mainly intended for
> >> >> > simplification and to allow authors to write a bash4/zsh/dash version
> >> >> > of poll(1) without having to implement compound variable support
> >> >> > first... ;-/ )
> >> >> > 2. If the input variable is a compound variable array or type variable
> >> >> > array "events" and "revents" should be compound variables themselves
> >> >> >
> >> >> > - Fix timeout when poll(2) needs to be restarted after EINTR/EAGAIN
> >> >> >
> >> >> > - EXAMPLES section in manpage... but I hit an issue with ']' ...
> >> >> > mhhh... AFAIK we had a similar request in the list this month: How do
> >> >> > I quote ']' that |_ast_getopts()| interprets it as plain text ?
> >> >
> >> >> When do you think will poll(1) be ready for integration into ast-ksh?
> >> >
> >> > it looks like today we will get the final ksh93u+ beta out
> >> > poll(1) integration will be with some ksh93v- alpha
> >
> >> Erm... please let me change the API first and add a test module...
> >
> >> > in the meantime, if poll(1) were added to cmdtst, it could be
> >> > tested with current ksh93u+ without recompilation
> >
> >> AFAIK this doesn't work because poll(1) depends on the |nv*()|-API and
> >> libshell internal APIs (like |tty_raw()| and |tty_cooked()|) ... but
> >> IMO you are right that something like that would be nice for _testing_
> >> purposes...
> >> ... what about adding a new libshellcmdtst which works like cmdtst but
> >> links against libshell ?
> >
> > that would require ksh and cmdtst both linked against shared/dll -lshell
> > the only system that does that by default is uwin because windows is
> > already dll giddy
> > unix shared lib startup times and bootstrap / sysadmin requirements make
> > ksh +lshell (libshell.a) the default
> Erm... I think you misunderstood me. There would be two cmdtst incarnations:
> 1. "cmdtst" - the current one, only links against libast
> 2. "shellcmdtst" - the new one, which links against libshell and libast
> In case of a static build both would be dumped into ksh93.
> > well, that may be a bit restrictive
> > if ksh were linked with +lshell and -lcmdtst linked with -lshell
> > and if the parts of -lshell used by -lcmdtst did not involved globals
> > (i.e., all ops relied on Shell_t*)
> > and if -lshell and +lshell were the same implementation modulo dynamic vs
> > static
> > then it would/should work
> >
> > I believe part of the ksh93v work will be to get the apis to that state
> Uhm... what exactly do you mean ?
there are currently 2 ways to build ksh
"+lshell +lcmd"
this links ksh main against libshell.a libcmd.a
and only b_*() builtins explicitly referenced in
src/cmd/ksh93/data/builtins.c are pulled in
pulling in -lcmd (shared/dll) at runtime works because
-lcmd has no globals -- *if* -lcmd had globals then
on some systems there could be 2 instantiations of those globals,
one from the original +lshell static link and one from the
runtime dlopen() of -lshell
"-lshell -lcmd"
this links the ksh main against shared/dll -lshell -lcmd
on all known systems dlopen() of -lcmd will be a no-op
because the main prog already has it when main() is entered
the "work to get it to that state" is what you have been advocating:
eliminate most or all globals in -lshell -lcmd and make all apis
take a handle instead -- a first requirement for getting threads to work
dgk's references to { stdin signals processes ttys } are cross-thread globals
we will have to deal with in a more complicated way than simply providing
handles
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
