Re: [PATCH] nextfd(2)

[KOSAKI Motohiro <kosaki.motohiro@gmail.com>]

(4/4/12 10:10 AM), Colin Walters wrote:
> On Wed, 2012-04-04 at 09:31 -0700, KOSAKI Motohiro wrote:
>
>> Ideally possible. but practically impossible. 2) people don't use a their
>> own malloc. they only uses open sources alternative malloc. And, I think
>> you have too narrowing concern. Even though malloc people adds a workaround,
>> the standard inhibit to use it
>
> What do you mean?  If as hpa says, the maintainer of e.g. google
> tcmalloc added a call to pthread_atfork(), then code which uses
> opendir() would start working.

 From point of application programmer view, they have no right to choose
malloc implementation. user can easily override it by using LD_PRELOAD.
So, even though one or two malloc implementation will be fixed, it doesn't
mean user land folks pain will gone. they are living more painful world.
At least, they told me so.

But, I discussed about this issue with hpa today and we agreed the best way is
to merge hpa fdwalk() into libc. It makes maximum happy, example, glib can drop
its own fdwalk implementation. so, I'd like to discuss libc folks.




>>   and people may continue to use more dangerous
>> RLIM_NOFILE loop. 1) I haven't seen _practical_ userland software uses such
>> linux internal hacking. Almost all major software can run on multiple OSs.
>
> Except that if you're using /proc/self/fd, you're already relying on
> Linux-specific functionality.  So it's not burdensome to use "struct
> linux_dirent" and O_DIRECTORY either.
>
> In GLib we're presently doing the regular /proc+opendir() under
> #ifdef __linux__:
> http://git.gnome.org/browse/glib/tree/glib/gspawn.c#n932
>
> Now I'd happily switch to hpa's fdwalk() implementation if I was aware
> of someone using glib in combination with an alternative malloc hitting
> this problem.
>
> Basically I think hpa is right here, and it's not really worth adding
> a new system call.
>
> The thing is, even if it were added today, since we need to run on old
> kernels, we'd have to carry the code to use the /proc trick
> approximately forever.  And in the end all nextfd() would accomplish
> would be a *third* case in the already messy ifdefs/fallbacks
> in the various implementations of process spawning.

Nope. some OSs only have a silly rlimit(RLIM_NOFILE), then userland continue
to keep rlimit(NOFILE) for fallback. it's no linux specific.

I mean, OpenJDK and glib already has a linux specific trick, but many software
don't.