apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: [PATCH] bucket type "capabilities" flags
Date Tue, 19 Jun 2001 12:32:39 GMT
On 19 Jun 2001, Jeff Trawick wrote:

> > +#define APR_BUCKET_FLAGNONE     0x00000000
> > +#define APR_BUCKET_FLAGSETASIDE 0x00000001
> > +#define APR_BUCKET_FLAGSPLIT    0x00000002
> > +#define APR_BUCKET_FLAGCOPY     0x00000004
> > +#define APR_BUCKET_FLAGSENDFILE 0x00000010
> > +#define APR_BUCKET_FLAGMETADATA 0x00000100
> > +#define APR_BUCKET_FLAGALLFNS						\
> > +        (APR_BUCKET_FLAGSETASIDE | APR_BUCKET_FLAGSPLIT | APR_BUCKET_FLAGCOPY)
>
> how about a '_' after FLAG?  as long as they are already we might as
> well make them a little more readable :)

Yeah... sadly, I was just trying to make them fit on one line in places
where they're used.  ;-)  I'll add the extra _.

> re APR_BUCKET_FLAGSENDFILE: all that matters is that the bucket
> represents an apr_file_t...  whether or not somebody is going to use
> apr_sendfile() or something else shouldn't be important to the bucket
> code, should it?  perhaps it should be renamed to APR_BUCKET_FLAGFILE

Hmm... well, not necessarily.  Just because it has a file descriptor in it
doesn't mean that it behaves like a file bucket in any OTHER way.  All the
flag means is that there exists a file descriptor in the bucket data
structure at a particular offset that you can use sendfile on.  Whether it
would be MMAPed upon read or whatever... well, that's a different flag, I
think.  No?

> a couple of really tiny nits about APR_BUCKET_FLAGALLFNS...
>
> . ALLFNS doesn't mean all functions, it just means all of the cool
>   things

No, it means all functions.  destroy() and read() are required, so if you
have the other three, you have all five of them.

> . ALLFNS will surely change in the future, but what is the way to get
>   the bucket types updated appropriately?  I suspect that if we do
>   away with ALLFNS and instead "spell it out" in the bucket type
>   definitions it will be most obvious what to update

Yeah, I guess... the lines just become prohibitively long.  But you're
right that it could cause problems if we added to it later.  <sigh>  Well,
I'll see what I can do... I don't suppose anyone would agree to a
"APR_BUCKET_FLAGTHREEOPTFNS" or something like that?

> would it be bad to have an accessor function for the file descriptor?
> otherwise, the doc for APR_BUCKET_FLAGSENDFILE should mention that if
> the bucket has this flag then the apr_file_t * has to be at the magic
> offset

It does mention that (well, actually, the APR_BUCKET_SUPPORTS_SENDFILE()
documentation mentions it... I guess a @see is appropriate at least).  An
accessor function is not needed; all you have to do is just pretend that
it's a FILE bucket.  It goes something like this:

    if (APR_BUCKET_SUPPORTS_SENDFILE(e)) {
        apr_bucket_file *f = e->data;
        apr_sendfile(sock, f->fd, ...);
    }

Easy, huh?

--Cliff


--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA



Mime
View raw message