Matt Dillon <[EMAIL PROTECTED]> wrote:
>
>We are *not* going create a separate ref count field just to track
>socket queue references, because this breaks the file descriptor passing
>semantics...
There is an f_msgcount field already but isn't used for the sort of
half-baked hack at t
I think there is some confusion over ref counts here. I'm going
to try to be clear: You *cannot* use a 1->0 transition on a ref
count to cleanup self referential loops in socket message queues
from file descriptor passing. Because no 1->0 transition will
ever occur, even if
* Terry Lambert <[EMAIL PROTECTED]> [001214 15:45] wrote:
> > >This still leaves the possibility of a circular reference being
> > >passed while being passed until the process exits, but I don't
> > >think you need to care about that.
> >
> > That's the whole point of this conversation!
>
> I do
> >This still leaves the possibility of a circular reference being
> >passed while being passed until the process exits, but I don't
> >think you need to care about that.
>
> That's the whole point of this conversation!
I don't think you need to care about it. There are valid reasons
for doing
> >SVR4 and Solaris avoid the problem entirely by ensuring that
> >each reference to a vnode pointer counts as an "open", and
> >the vnode can not be discarded until a 1->0 reference count
> >change (grep for VHOLD/VRELE/VREF in the Solaris headers).
>
> FreeBSD does this too. It doesn't solve th
Terry Lambert <[EMAIL PROTECTED]> wrote:
>
>SVR4 and Solaris avoid the problem entirely by ensuring that
>each reference to a vnode pointer counts as an "open", and
>the vnode can not be discarded until a 1->0 reference count
>change (grep for VHOLD/VRELE/VREF in the Solaris headers).
FreeBSD doe
> Ok, I'll see if that can happen. Basically since the reference
> never goes to zero on the socket, the buffers are never forced to
> be flushed/cleared and the mbuf will then never be free'd resulting
> it it leaking itself. Basically a socket hanging there with an
> mbuf referencing itself.
>
Tony Finch <[EMAIL PROTECTED]> wrote:
>
>R. D. Lins: "Cyclic Reference Counting with Local Mark-Scan";
>Information Processing Letters 44(4):215-220, 1992; University of Kent
>at Canterbury Computing Laboratory Technical Report 75, July 1990.
http://citeseer.nj.nec.com/lins90cyclic.html
Tony.
--
Tony Finch <[EMAIL PROTECTED]> wrote:
>
>Instead of the existing breadth-first search of the whole file table
>at the start of unp_gc, it should first clear the mark on each
>descriptor on the in-flight list, then do a depth-first search of all
>the descriptors reachable from the unix domain socke
Alfred Perlstein wrote:
>
> * Alfred Perlstein <[EMAIL PROTECTED]> [001213 14:20] wrote:
> > * Matt Dillon <[EMAIL PROTECTED]> [001213 13:07] wrote:
> > > :I believe that your changes have been sorely needed for many
> > > :years. While I would like to see regular mbufs given a callback
> > > :me
Matt Dillon <[EMAIL PROTECTED]> wrote:
>
>No waste at all, Alfred, the file descriptor passing code had been
>broken for over 10 years precisely because of its complexity. Rewriting
>the GC to be more efficient essentially requires using deep graph theory
>to locate isolated loops
:Hmm, the last time i looked at this, I believe the whole thing was
:dealt with by not increasing the file descriptor reference count
:when it was put in the message header. If process A closed the
:descriptor before process B actually recvmsg()d it, it would be
:EBADF. The recvmsg() actual
:> No waste at all, Alfred, the file descriptor passing code had been
:
:Are you saying the code in place is broken? If so I'll spend some
:time looking at it and the Linux implementation to figure if at
:least one of us gets it right and try to find some sort of solution.
No, *had*, no
* Matt Dillon <[EMAIL PROTECTED]> [001213 17:25] wrote:
>
> :I guess the gc has to stay.
> :
> :dammit. :)
> :
> :My apologies for wasting everyone's time here.
> :
> :--
> :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
>
> No waste at all, Alfred, the file descriptor passing co
:I guess the gc has to stay.
:
:dammit. :)
:
:My apologies for wasting everyone's time here.
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
No waste at all, Alfred, the file descriptor passing code had been
broken for over 10 years precisely because of its complexity.
> Brian Somers <[EMAIL PROTECTED]> wrote:
> >
> >Hmm, the last time i looked at this, I believe the whole thing was
> >dealt with by not increasing the file descriptor reference count
> >when it was put in the message header. If process A closed the
> >descriptor before process B actually recv
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>
>I guess the gc has to stay.
>
>dammit. :)
>
>My apologies for wasting everyone's time here.
``One day a student came to Moon and said: "I understand how to make a
better garbage collector. We must keep a reference count of the
pointers to each cons."
> This causes a leak, I think the trick is to just always call sorflush()
> when the pcb is free'd.
Even this doesn't work.
>
> Looking at linux they still are using gc. I'll give this a lot
> more thought before resubmitting this idea.
Ok, the problem is you have 3 af_unix pairs all open bet
Brian Somers <[EMAIL PROTECTED]> wrote:
>
>Hmm, the last time i looked at this, I believe the whole thing was
>dealt with by not increasing the file descriptor reference count
>when it was put in the message header. If process A closed the
>descriptor before process B actually recvmsg()d it, i
* Alfred Perlstein <[EMAIL PROTECTED]> [001213 14:20] wrote:
> * Matt Dillon <[EMAIL PROTECTED]> [001213 13:07] wrote:
> > :I believe that your changes have been sorely needed for many
> > :years. While I would like to see regular mbufs given a callback
> > :mechanism, your present approach of usi
* Matt Dillon <[EMAIL PROTECTED]> [001213 13:07] wrote:
> :I believe that your changes have been sorely needed for many
> :years. While I would like to see regular mbufs given a callback
> :mechanism, your present approach of using an mbuf cluster
> :solves 90% of the problem.
> :
> : Kirk Mc
> Not a lot of people are familiar with fd passing so I'll give
> a short description:
>
> By using AF_UNIX sockets between processes, a process can use
> sendmsg() to send a filedescriptor through the socket where the
> other process will do a recvmsg() to pickup the descriptor.
>
> The "
:I believe that your changes have been sorely needed for many
:years. While I would like to see regular mbufs given a callback
:mechanism, your present approach of using an mbuf cluster
:solves 90% of the problem.
:
: Kirk McKusick
... Aflred, be careful that you don't break things we
I believe that your changes have been sorely needed for many
years. While I would like to see regular mbufs given a callback
mechanism, your present approach of using an mbuf cluster
solves 90% of the problem.
Kirk McKusick
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscri
Not a lot of people are familiar with fd passing so I'll give
a short description:
By using AF_UNIX sockets between processes, a process can use
sendmsg() to send a filedescriptor through the socket where the
other process will do a recvmsg() to pickup the descriptor.
The "problem" is that
25 matches
Mail list logo
