At 05:52 PM 1/15/2010, Pierre A. Humblet wrote:
The scenario you describe (one packet only, with a long delay between accept
and WSAEventSelect) could easily be tested to settle the matter.
Put a sleep before fdsock !
To close the matter, I have done just that, putting a 60 s sleep in
On Jan 14 17:09, Corinna Vinschen wrote:
On Jan 14 08:39, Pierre A. Humblet wrote:
At 08:17 AM 1/14/2010, Corinna Vinschen wrote:
On Jan 14 06:02, Eric Blake wrote:
In a multi-threaded app, any fd that is opened only temporarily, such as
the one in mq_open, should be opened with
- Original Message -
From: Corinna Vinschen
To: cygwin-patches
Sent: Friday, January 15, 2010 10:42
| On Jan 14 17:09, Corinna Vinschen wrote:
| On Jan 14 08:39, Pierre A. Humblet wrote:
|
| For the same reason we should also have SOCK_CLOEXEC, and
| SOCK_NONBLOCK while we are
On Jan 15 21:22, Corinna Vinschen wrote:
On Jan 15 15:04, Pierre A. Humblet wrote:
I see an issue with accept/accept4 and was going to ask you how to
handle it.
Before your changes in Cygwin the socket returned by accept had the
same blocking (and async) property as the listening
- Original Message -
From: Corinna Vinschen
To: cygwin-patches
Sent: Friday, January 15, 2010 15:34
| On Jan 15 21:22, Corinna Vinschen wrote:
| On Jan 15 15:04, Pierre A. Humblet wrote:
| I see an issue with accept/accept4 and was going to ask you how to
| handle it.
|
|
On Jan 15 16:33, Pierre A. Humblet wrote:
From: Corinna Vinschen
| Oh, hang on. I guess we should better stick to the BSD behaviour.
| Any call to WSAAsyncSelect or WSAEventSelect clears Winsock's internal
| network event queue. This could lead to connection errors. Given
| that, the
- Original Message -
From: Corinna Vinschen
To: cygwin-patches
Sent: Friday, January 15, 2010 17:03
| On Jan 15 16:33, Pierre A. Humblet wrote:
| From: Corinna Vinschen
| | Oh, hang on. I guess we should better stick to the BSD behaviour.
| | Any call to WSAAsyncSelect or
On Jan 13 16:49, Christopher Faylor wrote:
On Wed, Jan 13, 2010 at 10:25:37PM +0100, Corinna Vinschen wrote:
Hi,
the below patch implements the Linux dup3/O_CLOEXEC/F_DUPFD_CLOEXEC
extension. I hope I didn't miss anything important since it affects
quite a few fhandlers. Fortunately most
On Jan 13 21:00, Eric Blake wrote:
According to Corinna Vinschen on 1/13/2010 2:25 PM:
Eric, you asked for it in the first place, do you have a fine testcase
for this functionality?
For dup3, fcntl(F_DUPFD_CLOEXEC), and pipe2, yes. For open, accept4, and
others, you'll have to use your
On Jan 13 21:00, Eric Blake wrote:
And while it looks
like mq_open should not care about O_CLOEXEC, there may be some cleanup
needed there.
It just occured to me that this an important hint. Message queue
descriptors are always closed-on-exec. Apparently I forgot to set the
close-on-exec
According to Corinna Vinschen on 1/14/2010 4:57 AM:
time to do that via the O_CLOEXEC flag.
Hang on, the file is closed anyway after the mmap call succeeded.
That's not true for sem_open and shm_open, though.
Well, on Linux, it looks like sem_open does not need to keep the fd open.
It all
According to Corinna Vinschen on 1/14/2010 3:25 AM:
+ if (flags O_CLOEXEC)
+ newfh-set_close_on_exec (true);
Is that a typo?
+ else
+ newfh-close_on_exec (false);
If not, why not just newfh-close_on_exec (!!(flags O_CLOEXEC)), instead
of the if-else?
There's a
On Jan 14 06:02, Eric Blake wrote:
According to Corinna Vinschen on 1/14/2010 4:57 AM:
time to do that via the O_CLOEXEC flag.
Hang on, the file is closed anyway after the mmap call succeeded.
That's not true for sem_open and shm_open, though.
Well, on Linux, it looks like sem_open
At 08:17 AM 1/14/2010, Corinna Vinschen wrote:
On Jan 14 06:02, Eric Blake wrote:
In a multi-threaded app, any fd that is opened only temporarily, such as
the one in mq_open, should be opened with O_CLOEXEC, so that no other
thread can win a race and do a fork/exec inside the window when
On Jan 14 08:39, Pierre A. Humblet wrote:
At 08:17 AM 1/14/2010, Corinna Vinschen wrote:
On Jan 14 06:02, Eric Blake wrote:
In a multi-threaded app, any fd that is opened only temporarily, such as
the one in mq_open, should be opened with O_CLOEXEC, so that no other
thread can win a
On Thu, Jan 14, 2010 at 10:40:27AM +0100, Corinna Vinschen wrote:
On Jan 13 16:49, Christopher Faylor wrote:
On Wed, Jan 13, 2010 at 10:25:37PM +0100, Corinna Vinschen wrote:
Hi,
the below patch implements the Linux dup3/O_CLOEXEC/F_DUPFD_CLOEXEC
extension. I hope I didn't miss anything
Hi,
here's the next iteration of the patch. It takes the comments to the
first iteration into account, adds the pipe2 call, and uses O_CLOEXEC in
the POSIX IPC foo_open calls. I also ran all three testcases provided
by Eric as well as a handcrafted test for open, which I created from the
pipe2
On Jan 14 11:26, Christopher Faylor wrote:
On Thu, Jan 14, 2010 at 10:40:27AM +0100, Corinna Vinschen wrote:
The combination with sec_none_nih/sec_none is used four times in
different fhandler files. Yes, good idea, I'll create an inline
function in fhandler.h.
The above combination with
On Thu, Jan 14, 2010 at 05:45:36PM +0100, Corinna Vinschen wrote:
On Jan 14 11:26, Christopher Faylor wrote:
On Thu, Jan 14, 2010 at 10:40:27AM +0100, Corinna Vinschen wrote:
The combination with sec_none_nih/sec_none is used four times in
different fhandler files. Yes, good idea, I'll create
On Thu, Jan 14, 2010 at 05:35:56PM +0100, Corinna Vinschen wrote:
Hi,
here's the next iteration of the patch. It takes the comments to the
first iteration into account, adds the pipe2 call, and uses O_CLOEXEC in
the POSIX IPC foo_open calls. I also ran all three testcases provided
by Eric as
On Jan 14 11:51, Christopher Faylor wrote:
On Thu, Jan 14, 2010 at 05:45:36PM +0100, Corinna Vinschen wrote:
No worries. Parts of my patch suffered from the same problem ;)
Part of my problem is that I've recently discovered Runes of Magic and
that has been occupying way too much of my
On Jan 14 11:54, Christopher Faylor wrote:
On Thu, Jan 14, 2010 at 05:35:56PM +0100, Corinna Vinschen wrote:
Hi,
here's the next iteration of the patch. It takes the comments to the
first iteration into account, adds the pipe2 call, and uses O_CLOEXEC in
the POSIX IPC foo_open calls. I
Hi,
the below patch implements the Linux dup3/O_CLOEXEC/F_DUPFD_CLOEXEC
extension. I hope I didn't miss anything important since it affects
quite a few fhandlers. Fortunately most is mechanical change, except
for a few places (dtable.cc, pipe.cc, fhandeler_fifo.cc, syscalls.cc).
Nevertheless
On Wed, Jan 13, 2010 at 10:25:37PM +0100, Corinna Vinschen wrote:
Hi,
the below patch implements the Linux dup3/O_CLOEXEC/F_DUPFD_CLOEXEC
extension. I hope I didn't miss anything important since it affects
quite a few fhandlers. Fortunately most is mechanical change, except
for a few places
According to Corinna Vinschen on 1/13/2010 2:25 PM:
Hi,
the below patch implements the Linux dup3/O_CLOEXEC/F_DUPFD_CLOEXEC
extension. I hope I didn't miss anything important since it affects
quite a few fhandlers.
Eric, you asked for it in the first place, do you have a fine testcase
On Wed, Jan 13, 2010 at 09:00:19PM -0700, Eric Blake wrote:
MALLOC_CHECK;
- debug_printf (dup2 (%d, %d), oldfd, newfd);
+ debug_printf (dup3 (%d, %d, %d), oldfd, newfd, flags);
I'd prefer %#x for flags, rather than %d (two instances in this function).
In that case it should be %p to be
26 matches
Mail list logo
