-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dean gaudet wrote:
> i'm not suggesting the library set the global flag. i'm suggesting that
> me as an app writer will do so.
>
> it seems like both methods are useful.
No, the global flag is hardly ever useful. You almost never know the
details
On Fri, 16 Nov 2007, Ulrich Drepper wrote:
> dean gaudet wrote:
> > honestly i think there should be a per-task flag which indicates whether
> > fds are by default F_CLOEXEC or not. my reason: third party libraries.
>
> Only somebody who thinks exclusively about applications as opposed to
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dean gaudet wrote:
> honestly i think there should be a per-task flag which indicates whether
> fds are by default F_CLOEXEC or not. my reason: third party libraries.
Only somebody who thinks exclusively about applications as opposed to
you know... i understand the need for FD_CLOEXEC -- in fact i tried
petitioning for CLOEXEC options to all the fd creating syscalls something
like 7 years ago when i was banging my head against the wall trying to
figure out how to thread apache... but even still i'm not convinced that
On Fri, 16 Nov 2007, Ulrich Drepper wrote:
dean gaudet wrote:
honestly i think there should be a per-task flag which indicates whether
fds are by default F_CLOEXEC or not. my reason: third party libraries.
Only somebody who thinks exclusively about applications as opposed to
you know... i understand the need for FD_CLOEXEC -- in fact i tried
petitioning for CLOEXEC options to all the fd creating syscalls something
like 7 years ago when i was banging my head against the wall trying to
figure out how to thread apache... but even still i'm not convinced that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dean gaudet wrote:
honestly i think there should be a per-task flag which indicates whether
fds are by default F_CLOEXEC or not. my reason: third party libraries.
Only somebody who thinks exclusively about applications as opposed to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dean gaudet wrote:
i'm not suggesting the library set the global flag. i'm suggesting that
me as an app writer will do so.
it seems like both methods are useful.
No, the global flag is hardly ever useful. You almost never know the
details of
Ulrich Drepper a écrit :
This is a first user of sys_indirect. Several of the socket-related system
calls which produce a file handle now can be passed an additional parameter
to set the FD_CLOEXEC flag.
- retval = sock_map_fd(sock);
+ retval = sock_map_fd_flags(sock,
This is a first user of sys_indirect. Several of the socket-related system
calls which produce a file handle now can be passed an additional parameter
to set the FD_CLOEXEC flag.
socket.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
--- a/net/socket.c
+++
This is a first user of sys_indirect. Several of the socket-related system
calls which produce a file handle now can be passed an additional parameter
to set the FD_CLOEXEC flag.
socket.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
--- a/net/socket.c
+++
Ulrich Drepper a écrit :
This is a first user of sys_indirect. Several of the socket-related system
calls which produce a file handle now can be passed an additional parameter
to set the FD_CLOEXEC flag.
- retval = sock_map_fd(sock);
+ retval = sock_map_fd_flags(sock,
12 matches
Mail list logo