httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Fwd: file bucket native operations
Date Mon, 27 Nov 2000 17:52:29 GMT

> > 3)  We dup a file and it shows up in two buckets.  This isn't case we need
> > to worry about, because it can be treated as if we were just dealing with
> > files instead of buckets.
> Err... no.  If I understand precisely the case you're talking about, that is.  At
> least on some OSes (maybe all, maybe not, I don't know), dup() causes the original
> and the dup'ed file descriptor to share file pointers (and therefore we need to
> refcount/serialize)... at least Linux does this, according to its man page.

You missed my point.  This isn't a case that the buckets need to deal
with, because we would have the exact same issue if we weren't using
buckets.  If we ever dup a file, then we have this issue, so it is
completely orthogonal to the buckets idea.

> But anyway, if the code dumps an fd into a bucket, shouldn't it only ever be the
> buckets code that deals directly with that fd from then on?  As far as the

There is no rule that says just because the fd is in a bucket it can't be
accessed any other way.  In fact, I would venture to say that that
statement is unworkable in the long run.

> file-opener code is concerned, it just has a file bucket from that point on, not an
> open file that it's still allowed to play with.  The buckets code will manipulate
> the fd, the pool code will close it when the pool dies.  The caller never has to
> touch it again.

That doesn't work once you try to deal with cache'ing file handles.

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message