From: casper@oracle.com
> Sent: 21 October 2015 21:33
..
> >Er... So fd2 = dup(fd);accept(fd)/close(fd) should *not* trigger that
> >behaviour, in your opinion? Because fd is sure as hell not the last
> >descriptor refering to that socket - fd2 remains alive and well.
> >
> >Behaviour you
On Mon, Nov 02, 2015 at 10:03:58AM +, David Laight wrote:
> Remember, Solaris (and SYSV) has extra levels of multiplexing between
> userspace and char special drivers (and probably sockets) than Linux does.
> As well as having multiple fd referencing the same struct FILE, multiple
> FILE can
On Wed, Oct 21, 2015 at 03:38:51PM +0100, Alan Burlison wrote:
> On 21/10/2015 04:49, Al Viro wrote:
> >BTW, for real fun, consider this:
> >7)
> >// fd is a socket
> >fd2 = dup(fd);
> >in thread A: accept(fd);
> >in thread B: accept(fd);
> >in thread C: accept(fd2);
> >in thread D:
On Fri, Oct 23, 2015 at 06:30:25PM +, David Holland wrote:
> So, I'm coming late to this discussion and I don't have the original
> context; however, to me this cited behavior seems undesirable and if I
> ran across it in the wild I would probably describe it as a bug.
Unfortunately, that's
On Thu, Oct 22, 2015 at 11:55:42AM +0100, Alan Burlison wrote:
> On 22/10/2015 05:21, Al Viro wrote:
>
> >>Most of the work on using a file descriptor is local to the thread.
> >
> >Using - sure, but what of cacheline dirtied every time you resolve a
> >descriptor to file reference?
>
> Don't
On 22/10/2015 05:21, Al Viro wrote:
Most of the work on using a file descriptor is local to the thread.
Using - sure, but what of cacheline dirtied every time you resolve a
descriptor to file reference?
Don't you have to do that anyway, to do anything useful with the file?
How much does
On 22/10/15 19:16, Al Viro wrote:
Don't you have to do that anyway, to do anything useful with the file?
Dirtying the cacheline that contains struct file itself is different, but
that's not per-descriptor.
Yes, true enough.
Usually it's per-process, but any thread could ask for a private
On Wed, 2015-10-21 at 14:03 +0100, Alan Burlison wrote:
> On 21/10/2015 12:28, Eric Dumazet wrote:
>
> > This works for me. Please double check your programs
>
> I have just done so, it works as you say for AF_INET sockets but if you
> switch to AF_UNIX sockets it does the wrong thing in the
On 21/10/2015 04:49, Al Viro wrote:
Firstly, thank you for the comprehensive and considered reply.
Refcount is an implementation detail, of course. However, in any Unix I know
of, there are two separate notions - descriptor losing connection to opened
file (be it from close(), exit(),
On Wed, Oct 21, 2015 at 10:33:04PM +0200, casper@oracle.com wrote:
>
> >On Wed, Oct 21, 2015 at 03:38:51PM +0100, Alan Burlison wrote:
> >
> >> >There's going to be a notion of "last close"; that's what this refcount is
> >> >about and _that_ is more than implementation detail.
> >>
> >>
On Wed, 2015-10-21 at 15:38 +0100, Alan Burlison wrote:
> --
> Since at least Solaris 7 (1998), a thread which is sleeping
> on a file descriptor which is being closed by another thread,
> will be woken up.
>
> To this end each thread keeps a list of file descriptors
> in use by the
On Wed, Oct 21, 2015 at 03:38:51PM +0100, Alan Burlison wrote:
> >There's going to be a notion of "last close"; that's what this refcount is
> >about and _that_ is more than implementation detail.
>
> Yes, POSIX distinguishes between "file descriptor" and "file
> description" (ugh!) and the
>On Wed, Oct 21, 2015 at 03:38:51PM +0100, Alan Burlison wrote:
>
>> >There's going to be a notion of "last close"; that's what this refcount is
>> >about and _that_ is more than implementation detail.
>>
>> Yes, POSIX distinguishes between "file descriptor" and "file
>> description" (ugh!) and
On 21/10/2015 19:51, Al Viro wrote:
BTW, is SCM_RIGHTS outside of scope? They do mention it in one place
only:
| Ancillary data is also possible at the socket level. The
| header shall define the following symbolic constant for use as the cmsg_type
| value when cmsg_level is SOL_SOCKET:
|
|
On 21/10/2015 12:28, Eric Dumazet wrote:
This works for me. Please double check your programs
I have just done so, it works as you say for AF_INET sockets but if you
switch to AF_UNIX sockets it does the wrong thing in the way I described.
--
Alan Burlison
--
--
To unsubscribe from this
From: Alan Burlison
> Sent: 20 October 2015 19:31
...
> The problem with poll() is that it returns immediately when passed a FD
> that is in the listening state. rather than waiting until there's an
> incoming connection to handle. As I said, that means you can't use
> poll() to multiplex between
On 21/10/2015 11:25, David Laight wrote:
The problem with poll() is that it returns immediately when passed a FD
that is in the listening state. rather than waiting until there's an
incoming connection to handle. As I said, that means you can't use
poll() to multiplex between read/write/accept
On Wed, 2015-10-21 at 11:49 +0100, Alan Burlison wrote:
> On 21/10/2015 11:25, David Laight wrote:
>
> >> The problem with poll() is that it returns immediately when passed a FD
> >> that is in the listening state. rather than waiting until there's an
> >> incoming connection to handle. As I
On 20/10/2015 02:45, Eric Dumazet wrote:
On Tue, 2015-10-20 at 02:12 +0100, Alan Burlison wrote:
Another problem is that if I call close() on a Linux socket that's in
accept() the accept call just sits there until there's an incoming
connection, which succeeds even though the socket is
On 20/10/2015 16:30, Eric Dumazet wrote:
A close() does _not_ wakeup an accept() or a poll() (this is exactly the
same problem), or any blocking system call using the same 'file'
Not waking up the accept() is one thing, allowing the accept() to
successfully complete some indeterminate time
On Tue, 2015-10-20 at 19:31 +0100, Alan Burlison wrote:
> No, the race issue with file descriptor reuse and the close() behaviour
> are not the same thing. The manpage comment is correct, but not relevant.
Ok, it seems you know better than me, I will be stop the discussion and
wait for your
On Tue, 2015-10-20 at 14:45 +0100, Alan Burlison wrote:
> And I still haven't seen any reasoning behind the Linux close() and
> poll() behaviour on sockets that are in the listen state.
Same answer.
A close() does _not_ wakeup an accept() or a poll() (this is exactly the
same problem), or any
On Mon, Oct 19, 2015 at 06:45:32PM -0700, Eric Dumazet wrote:
> On Tue, 2015-10-20 at 02:12 +0100, Alan Burlison wrote:
>
> > Another problem is that if I call close() on a Linux socket that's in
> > accept() the accept call just sits there until there's an incoming
> > connection, which
On Tue, 2015-10-20 at 10:59 +0100, Alan Burlison wrote:
> That may be how Linux implements accept(), but I don't see anything
> about refcounting in the POSIX spec for accept().
That's an internal implementation detail. POSIX does not document linux
kernel overall design and specific tricks.
On 20/10/2015 14:19, Eric Dumazet wrote:
That may be how Linux implements accept(), but I don't see anything
about refcounting in the POSIX spec for accept().
That's an internal implementation detail. POSIX does not document linux
kernel overall design and specific tricks.
No, neither does
On Mon, 2015-10-19 at 09:59 -0700, Stephen Hemminger wrote:
> This looks like corner case, but worth forwarding.
>
> Begin forwarded message:
>
> Date: Mon, 19 Oct 2015 13:21:33 +
> From: "bugzilla-dae...@bugzilla.kernel.org"
>
> To:
On 20/10/2015 00:33, Eric Dumazet wrote:
It looks it is a long standing problem, right ?
Yep, seems so.
inet_shutdown() has this very specific comment from beginning of git
tree :
switch (sk->sk_state) {
...
/* Remaining two branches are temporary solution for missing
On Tue, 2015-10-20 at 02:12 +0100, Alan Burlison wrote:
> Another problem is that if I call close() on a Linux socket that's in
> accept() the accept call just sits there until there's an incoming
> connection, which succeeds even though the socket is supposed to be
> closed, but then an
28 matches
Mail list logo