On Wed, 29 Aug 2012 15:14:47 +0200 Cedric Blancher 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
> What's wrong with {b}? It sounds like the easier and more flexible
> solution - {a} adds a lot of functions and macros and {b} only adds
> macros and a single function.
lets add threads to the standard
hmm, resolving conflicts between process global resources and threads is too
hard,
let that be handled in user space (e.g., 1Mi different ways)
oh, what about pwd
lets add ~100 new syscalls to handle that
oh, and *at()ify the library apis too -- stdio, opendir, did I forget anything?
...
every new resource conflict seems to result in a flurry of new syscalls
and the old pardigms get thrown out
what if there were solutions that preserved some of the old paradigms?
or
*at() is not a solution to the thread problem
unless every stinking api ever written that deals with pathnames has an *at()
variant
otherwise how do you get them to agree what the thread pwd is?
seems like a perfect place for standardization
but the standards gave us *at() instead
now, ranting a bit less
suppose you have n threads each with its own thread-pwd
how do those threads spawn processes, each with the thread-pwd of the parent?
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
