On 12/30/10 16:19, Bruce Korb wrote:
> On 12/12/10 03:49, Bruno Haible wrote:
>> Very good point. The dependency comes from
>>
>> openat --> openat-die --> error
>> fdopendir
>
> fdopendir --> openat --> ...
Woops:
--> ??? --> xalloc-die --> error
I'm ifdef-ing the error code for xal
On 12/12/10 03:49, Bruno Haible wrote:
> Very good point. The dependency comes from
>
> openat --> openat-die --> error
> fdopendir
fdopendir --> openat --> ...
> Can you work on breaking this dependency?
I have hacked around it thus and am currently testing:
$ git diff|cat
diff --g
Le jeudi 23 décembre 2010 19:56:38, Paul Eggert a écrit :
> On 12/23/2010 06:13 AM, Jim Meyering wrote:
> inclined to think that going with subprocesses would be more
> trouble than it's worth.
So be simple, for each openat fork and pass fd to parent process.
Bastien
On 12/23/2010 06:13 AM, Jim Meyering wrote:
> Starting a daemon...
> Yes, that sounds challenging.
We'd have to start a new daemon for each directory, right?
So we'd need a hash table mapping directory FDs to info about
each daemon.
There's also the issue of signal safety, which we'd need to
thin
Bastien ROUCARIÈS wrote:
> We could amortize the fork daemonize the daemon only once but we must
> care about security... but i could be done if fork is prohibitive.
Starting a daemon...
Yes, that sounds challenging.
> Unfortunatly context switching is the main cost so, i expext a heavy use
>
> H
Bastien ROUCARIES wrote:
> If chdir is a problem, why not using a heavy weight approach (better safe than
> sorry particularly if gnulib is used for a lot of project):
> - fork and exec an helper for name resolution
> - pass fd using a socket
>
> It is really heavy but it is on the safe side
Expen
do is figure out what in
>>>> libposix is dragging in error(), and work on breaking that dependency.
>>>> That way, a package using libposix then makes their own decision of
>>>> whether to supplement things with error() and program_name.
>>>
>>&
If chdir is a problem, why not using a heavy weight approach (better safe
than sorry particularly if gnulib is used for a lot of project):
- fork and exec an helper for name resolution
- pass fd using a socket
It is really heavy but it is on the safe side
Bastien
Le 23 déc. 2010 03:12, "Paul Egg
On 12/22/2010 03:32 PM, Bruno Haible wrote:
> For example, if save_cwd called
> currdir_fd = open (".");
> then on a platform that supports fchdir() natively [not gnulib's
> emulation], a failure to do fchdir (currdir_fd) is of type (a).
> It can only occur if some other part of the program did
ckage using libposix then makes their own decision of
>> whether to supplement things with error() and program_name.
>
> I replied:
>> Very good point. The dependency comes from
>>
>> openat --> openat-die --> error
>> fdopendir
>>
>> Can
Hi Jim, Eric,
> IMHO, those functions must never return in the unusual case for which
> they now call error and then exit. The failures are too fundamental[0],
> and we cannot require that all callers handle any new error code or
> interpret existing error codes differently, can we?
>
> [0] if o
ix is dragging in error(), and work on breaking that dependency.
>>> That way, a package using libposix then makes their own decision of
>>> whether to supplement things with error() and program_name.
>>
>> I replied:
>>> Very good point. The dependency comes from
at way, a package using libposix then makes their own decision of
>> whether to supplement things with error() and program_name.
>
> I replied:
>> Very good point. The dependency comes from
>>
>> openat --> openat-die --> error
>> fdopendir
>>
r own decision of
> whether to supplement things with error() and program_name.
I replied:
> Very good point. The dependency comes from
>
> openat --> openat-die --> error
> fdopendir
>
> Can you work on breaking this dependency? I mean, for example,
>
not POSIX. Maybe the thing to do is figure out what in
> libposix is dragging in error(), and work on breaking that dependency.
> That way, a package using libposix then makes their own decision of
> whether to supplement things with error() and program_name.
Very good point. The depe
15 matches
Mail list logo
