On 13 September 2012 19:17, Glenn Fowler <g...@research.att.com> wrote: > > On Thu, 13 Sep 2012 18:21:19 +0200 Lionel Cons wrote: >> On 13 September 2012 17:16, Glenn Fowler <g...@research.att.com> wrote: >> > >> > 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 > >> I hope the madness of trying to add a thread global current working >> directory is off the table, right? I've brought that up with my own >> staff in a meeting, earning me horrified faces and a stern education >> why this is a bad idea. > > not global > opt-in for ast only
I just hope applications compiled with libast stdio and sfio can still opt-out. This would be a very mission-critical thing - globals and thread globals are a bit nonono when scalability is required. Just look at AMD Nova, those machines will scale to 128 sockets in a ccNUMA cabinet, but it will suck performance wise if the applications are designed the wrong way. Lionel _______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers