You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Manoj Kasichainula <ma...@io.com> on 2000/03/02 23:21:58 UTC
Re: cvs commit: apache-2.0/src/main buff.c
On Thu, Mar 02, 2000 at 09:45:08AM -0000, dgaudet@locus.apache.org wrote:
> @@ -382,11 +399,7 @@
> rv = read_with_errors(fb, buf, nbyte, &i);
> if (rv != APR_SUCCESS) {
> *bytes_read = nrd;
> -#ifdef MIDWAY_ERROR_RETURNS_ERROR_BLAH_BLAH_BLAH
> return rv;
> -#else
> - return *bytes_read ? APR_SUCCESS : rv;
> -#endif
Hmmm. So now, the buff calls return errors even when bytes have been
successfully read or written. This wasn't what you wanted to do
before.
Re: cvs commit: apache-2.0/src/main buff.c
Posted by Manoj Kasichainula <ma...@io.com>.
[Today, I've caught up with list mail from December...]
On Sun, Mar 12, 2000 at 09:41:22AM -0800, Dean Gaudet wrote:
> On Tue, 7 Mar 2000, Manoj Kasichainula wrote:
>
> > On Thu, Mar 02, 2000 at 02:48:47PM -0800, Dean Gaudet wrote:
> > > On Thu, 2 Mar 2000, Manoj Kasichainula wrote:
> > > > Hmmm. So now, the buff calls return errors even when bytes have been
> > > > successfully read or written. This wasn't what you wanted to do
> > > > before.
> > >
> > > bwrite and bread do, sure. but i didn't propagate that into the rest of
> > > the buffered operations... dunno really, it was the only thing which made
> > > sense -- since i needed the info the whole way up the call chain.
OK, the quick way to ask my question: Why is the error status needed
before ap_b{read,write} gets called again?
> > OK, since I'm too lazy to figure this out...
>
> i didn't touch ap_bread, ap_bwrite prototypes, so i assume you've already
> propagated the necessary ap_status_t changes to the rest of the code...
Yup.
> and to be honest, i'm too lazy to go look at the code again. if it
> bothers you, then you do it. :)
meaniehead.
> > Why is that error status needed immediately? With the old POSIX-like
> > behavior, the call chain would get APR_SUCCESS and the number of bytes
> > successfully written. It would process all that, be happy, then try to
> > read more and get the error. With this change, now the error is
> > propogated up immediately.
>
> please distinguish between "propagated up through internal functions
> within buff.c" and "propagated up to the buff.c callers" 'cause your
> language is too confusing to parse.
The latter. Callers of ap_bread and ap_bwrite to be specific.
> > This is a good thing, but we were worried at one point that the rest
> > of the Apache code doesn't know how to deal with both bytes and an
> > error code.
>
> like i said, i didn't touch the ap_bread/bwrite prototypes... so i'm not
> sure what you're asking about.
The prototypes support both modes of operation. The #defines you
removed only selected whether the added flexibility of error+bytes at
the same time was actually used. Now it is, which I think is a good
thing, but 3rd-party modules (and maybe some Apache code) will have to
be prepared for this.
Re: cvs commit: apache-2.0/src/main buff.c
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 7 Mar 2000, Manoj Kasichainula wrote:
> On Thu, Mar 02, 2000 at 02:48:47PM -0800, Dean Gaudet wrote:
> > On Thu, 2 Mar 2000, Manoj Kasichainula wrote:
> > > Hmmm. So now, the buff calls return errors even when bytes have been
> > > successfully read or written. This wasn't what you wanted to do
> > > before.
> >
> > bwrite and bread do, sure. but i didn't propagate that into the rest of
> > the buffered operations... dunno really, it was the only thing which made
> > sense -- since i needed the info the whole way up the call chain.
>
> OK, since I'm too lazy to figure this out...
i didn't touch ap_bread, ap_bwrite prototypes, so i assume you've already
propagated the necessary ap_status_t changes to the rest of the code...
and so i'm not really sure at all what you're confused about.
and to be honest, i'm too lazy to go look at the code again. if it
bothers you, then you do it. :)
> Why is that error status needed immediately? With the old POSIX-like
> behavior, the call chain would get APR_SUCCESS and the number of bytes
> successfully written. It would process all that, be happy, then try to
> read more and get the error. With this change, now the error is
> propogated up immediately.
please distinguish between "propagated up through internal functions
within buff.c" and "propagated up to the buff.c callers" 'cause your
language is too confusing to parse.
> This is a good thing, but we were worried at one point that the rest
> of the Apache code doesn't know how to deal with both bytes and an
> error code.
like i said, i didn't touch the ap_bread/bwrite prototypes... so i'm not
sure what you're asking about.
Dean
Re: cvs commit: apache-2.0/src/main buff.c
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Mar 02, 2000 at 02:48:47PM -0800, Dean Gaudet wrote:
> On Thu, 2 Mar 2000, Manoj Kasichainula wrote:
> > Hmmm. So now, the buff calls return errors even when bytes have been
> > successfully read or written. This wasn't what you wanted to do
> > before.
>
> bwrite and bread do, sure. but i didn't propagate that into the rest of
> the buffered operations... dunno really, it was the only thing which made
> sense -- since i needed the info the whole way up the call chain.
OK, since I'm too lazy to figure this out...
Why is that error status needed immediately? With the old POSIX-like
behavior, the call chain would get APR_SUCCESS and the number of bytes
successfully written. It would process all that, be happy, then try to
read more and get the error. With this change, now the error is
propogated up immediately.
This is a good thing, but we were worried at one point that the rest
of the Apache code doesn't know how to deal with both bytes and an
error code.
Re: cvs commit: apache-2.0/src/main buff.c
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 2 Mar 2000, Manoj Kasichainula wrote:
> On Thu, Mar 02, 2000 at 09:45:08AM -0000, dgaudet@locus.apache.org wrote:
> > @@ -382,11 +399,7 @@
> > rv = read_with_errors(fb, buf, nbyte, &i);
> > if (rv != APR_SUCCESS) {
> > *bytes_read = nrd;
> > -#ifdef MIDWAY_ERROR_RETURNS_ERROR_BLAH_BLAH_BLAH
> > return rv;
> > -#else
> > - return *bytes_read ? APR_SUCCESS : rv;
> > -#endif
>
> Hmmm. So now, the buff calls return errors even when bytes have been
> successfully read or written. This wasn't what you wanted to do
> before.
bwrite and bread do, sure. but i didn't propagate that into the rest of
the buffered operations... dunno really, it was the only thing which made
sense -- since i needed the info the whole way up the call chain.
Dean