Re: [PATCH] nextfd(2)
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
(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 itWhat 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux Ext4 Filesystem] [Ecryptfs] [AutoFS] [Kernel Newbies] [Share Photos] [Security] [Netfilter] [Bugtraq] [Photo] [Yosemite] [Yosemite News] [MIPS Linux] [ARM Linux] [Linux Security] [Linux Cachefs] [Reiser Filesystem] [Linux RAID] [Samba] [Video 4 Linux] [Device Mapper] [CEPH Filesystem]