Discussion:
reference counts on sockets?
(too old to reply)
Thor Lancelot Simon
2008-09-24 19:59:52 UTC
Permalink
I have an in-kernel consumer of the socket API, which uses a very large
number of sockets. I don't want to maintain file structures associated
with all these sockets unless I absolutely must -- they're wasteful, and
kernel memory is at a premium.

The problem is that some of the code in the socket layer assumes that if
SS_NOFDREF is set, a socket's not long for this world and can be killed
off. This seems like a poor substitute for a real reference counter, and
mingles the semantics "has no associated file descriptor" and "is being
deallocated" besides.

I'd like to add reference counts to sockets, either manipulated under
the socket lock, or by atomic operations. Opinions?
--
Thor Lancelot Simon ***@rek.tjls.com
"Even experienced UNIX users occasionally enter rm *.* at the UNIX
prompt only to realize too late that they have removed the wrong
segment of the directory structure." - Microsoft WSS whitepaper

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
der Mouse
2008-09-24 20:17:51 UTC
Permalink
Post by Thor Lancelot Simon
I have an in-kernel consumer of the socket API, which uses a very
large number of sockets. I don't want to maintain file structures
associated with all these sockets unless I absolutely must -- they're
wasteful, and kernel memory is at a premium.
The problem is that some of the code in the socket layer assumes that
if SS_NOFDREF is set, a socket's not long for this world and can be
killed off.
Is it reasonable to just not set SS_NOFDREF, even though there truly is
no fd referring to the socket? That's what I think I did last time I
had to work with kernel-owned sockets. (Admittedly, that "last time"
was (a) years ago and (b) under NetBSD much older than what I assume
you are working with.)
Post by Thor Lancelot Simon
This seems like a poor substitute for a real reference counter, and
mingles the semantics "has no associated file descriptor" and "is
being deallocated" besides.
I suspect it does not have the former semantics except to humans; I
think the actual semantics are more like "not referrable-to any
longer", and the NOFDREF name is (at least now) a bit of a misnomer.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Andrew Doran
2008-09-25 14:49:41 UTC
Permalink
Post by Thor Lancelot Simon
I have an in-kernel consumer of the socket API, which uses a very large
number of sockets. I don't want to maintain file structures associated
with all these sockets unless I absolutely must -- they're wasteful, and
kernel memory is at a premium.
The problem is that some of the code in the socket layer assumes that if
SS_NOFDREF is set, a socket's not long for this world and can be killed
off. This seems like a poor substitute for a real reference counter, and
mingles the semantics "has no associated file descriptor" and "is being
deallocated" besides.
I'd like to add reference counts to sockets, either manipulated under
the socket lock, or by atomic operations. Opinions?
I think it's a good idea. I wanted to do the same along with the socket
locking but SS_NOFDREF seems a bit overloaded, so I left it.

Andrew

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...