On Tue, 05 Oct 2004 14:02:20 -0400, Allan Edwards <[EMAIL PROTECTED]> wrote:
> > I'm like Jeff, I won't lose any sleep if we just say that
> > 64 bit APR 1.0 cannot handle very large memory objects and go
> > the path of validating restricting and casting. At least let's
> > pursue that path and se
On Tue, 5 Oct 2004, Joe Orton wrote:
> Right, the bug is in how the function is used. It's the same as calling
> apr_file_write() and presuming it won't return short. The fix is to
> call apr_file_write_full(), in that case. In this case, there is no
> apr_file_writev_full(), so that should be
On Tue, Oct 05, 2004 at 11:23:35AM -0600, Jean-Jacques Clar wrote:
> >>> <[EMAIL PROTECTED]> 10/05/04 12:16 AM >>>
> On Mon, Oct 04, 2004 at 06:11:57PM -0600, Jean-Jacques Clar wrote:
> >> If HAS_WRITEV is not defined the current code
> >> will just push the first vector to the target.
> >> The fun
As I get no followup to my question, I'll just proceed with this patch and
do the other previously discussed renames in the same fashion. Correct?
Stas Bekman wrote:
Justin Erenkrantz wrote:
--On Sunday, September 19, 2004 8:19 PM -0400 Stas Bekman
<[EMAIL PROTECTED]> wrote:
FILE_OPEN_ is incon
I'm like Jeff, I won't lose any sleep if we just say that
64 bit APR 1.0 cannot handle very large memory objects and go
the path of validating restricting and casting. At least let's
pursue that path and see how ugly it gets.
Going with plan 'B'... I tend to think it would be useful to
use a #defin
>>> <[EMAIL PROTECTED]> 10/05/04 12:16 AM >>>
On Mon, Oct 04, 2004 at 06:11:57PM -0600, Jean-Jacques Clar wrote:>> If HAS_WRITEV is not defined the current code>> will just push the first vector to the target.>> The function should write all the vectors or none.>There is no guarantee that writev(2
On Mon, Oct 04, 2004 at 06:11:57PM -0600, Jean-Jacques Clar wrote:
> If HAS_WRITEV is not defined the current code
> will just push the first vector to the target.
> The function should write all the vectors or none.
There is no guarantee that writev(2) writes all the vectors, it's
allowed to retu
Joe Orton wrote:
Thanks for persevering with this. Some review below - which of the
implementations have you tested with this?
The attached, updated patch, has been tested on:
EPoll: None. (I tested the patch I sent earlier today with EPoll, and it
worked. I just don't have access to any machine
On Mon, 4 Oct 2004, Jean-Jacques Clar wrote:
> >> +if ((rv = apr_file_write(thefile, vec[i].iov_base, nbytes))
>
> I thought that the nbytes on the call for apr_file_write() is the
> number of bytes to write.
Oh crap, I'm sorry, I totally missed that. *blush*
+1 to the patch as-is.
--C
>>> Cliff Woolley <[EMAIL PROTECTED]> 10/04/04 7:08 PM >>>
>> + *nbytes = vec[i].iov_len;>Is there really a point to the above line? *nbytes will always be>overwritten before returning anyway, so why not just skip this line and>then:>> + if ((rv = apr_file_write(thefile, vec[i].iov_
On Mon, 4 Oct 2004, Jean-Jacques Clar wrote:
> If HAS_WRITEV is not defined the current code
> will just push the first vector to the target.
Oooh, that sucks. Good catch.
> The function should write all the vectors or none.
> I propose the following patch, comments will be
+1, with the follo
If HAS_WRITEV is not defined the current code
will just push the first vector to the target.
The function should write all the vectors or none.
I propose the following patch, comments will be
appreciated:
Thanks for looking.
JJ
Index: srclib/apr/file_io/unix/readwrite.c=
On Mon, Oct 04, 2004 at 01:34:29PM -0700, Paul Querna wrote:
> Attached is a patch that combines my previous patches:
> - Adds an APR_POLLSET_THREADSAFE Flag. When this flag is passed, there
> is thread safety between _add() and _remove().
> - Uses APR Rings to store Pollfds in the Pollsets for K
13 matches
Mail list logo
