On 29 August 2012 15:28, Glenn Fowler <g...@research.att.com> wrote:
>
> 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?
fchdir() after fork() but before exec()? :)
Seriously, that's a question for Olga and Roland to ask.
Lionel
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
