At 07:54 PM 11/21/2003, Brian Havard wrote:
>> Brian - can you make sure the OS/2 code is OK?
>
>yeah, it works, but it would have been better to resurrect poll.c rather
>than lump apr_poll() in with pollset.c.
I concur, since Win32 will have a replacement for apr_poll once I work out
where the t
On 21 Nov 2003 19:50:03 -, [EMAIL PROTECTED] wrote:
>dreid 2003/11/21 11:50:02
>
> Modified:include apr_poll.h
> poll/os2 pollset.c
> poll/unix poll.c
> Log:
> Add back apr_poll as it shouldn't have been removed.
>
> apr_poll is only intended for qu
Norman Tuttle wrote:
Please add back for Windows as well.
Doesn't Windows use apr/poll/unix/poll.c?
BTW, any testing you can do to make sure the right bits got put back is much
appreciated!
Hmm, well I didn't see any files in the poll/win32 directory (in fact there
wasn't one on my system) so that's why I didn't. If you have what needs to
be added back then why not submit a patch :)
david
> Please add back for Windows as well.
>
> [EMAIL PROTECTED] wrote:
>
> >dreid 2003/11/2
Please add back for Windows as well.
[EMAIL PROTECTED] wrote:
dreid 2003/11/21 11:50:02
Modified:include apr_poll.h
poll/os2 pollset.c
poll/unix poll.c
Log:
Add back apr_poll as it shouldn't have been removed.
apr_poll is only intended for quick polling.
The deprecated apr_poll APIs are still being referenced in several
places within Apache (ie. mod_ext_filter.c, proxy_connect.c, several
mpm's, etc.) Are these references being cleaned up or is that work to
be done? Currently the 2.1 HEAD does not build.
Brad
Brad Nicholes
Senior Software Eng
Brian Pane wrote:
On Fri, 2003-01-03 at 08:05, Joe Orton wrote:
On Tue, Dec 31, 2002 at 05:10:40PM -, William Rowe wrote:
Modified:poll/unix poll.c
Log:
Fix apr_poll behavior on Darwin/Win32 (now passing testpoll.)
We were getting spurious returned events because the select-
On Fri, 2003-01-03 at 08:05, Joe Orton wrote:
> On Tue, Dec 31, 2002 at 05:10:40PM -, William Rowe wrote:
> > Modified:poll/unix poll.c
> > Log:
> > Fix apr_poll behavior on Darwin/Win32 (now passing testpoll.)
> > We were getting spurious returned events because the select-base
On Tue, Dec 31, 2002 at 05:10:40PM -, William Rowe wrote:
> Modified:poll/unix poll.c
> Log:
> Fix apr_poll behavior on Darwin/Win32 (now passing testpoll.)
> We were getting spurious returned events because the select-based
> poll implementation wasn't zeroing out previous
On Fri, Aug 02, 2002 at 01:58:25PM -0700, Ryan Bloom wrote:
> Huh? We don't have any logic to tell apr_palloc how to die. The
> assumption is that if the server runs out of memory, then apr_palloc
> will return NULL, and the code will seg fault. The exact same
> assumption can be made for malloc
On Fri, 2 Aug 2002, Ryan Bloom wrote:
> Huh? We don't have any logic to tell apr_palloc how to die.
Sure we do. You just set an abort function. See line 631 of apr_pools.c.
--Cliff
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
>
> At 01:59 PM 8/2/2002, Ryan Bloom wrote:
> > > Modified:poll/unix poll.c
> > > Log:
> > > We safely ignore palloc failures [we can segv in the
allocator].
> > > We cannot ignore alloca/malloc failures.
> >
> >We generally ig
At 01:59 PM 8/2/2002, Ryan Bloom wrote:
> Modified:poll/unix poll.c
> Log:
> We safely ignore palloc failures [we can segv in the allocator].
> We cannot ignore alloca/malloc failures.
We generally ignore memory allocation errors of all kinds in the server
and APR. The general thou
> Modified:poll/unix poll.c
> Log:
> We safely ignore palloc failures [we can segv in the allocator].
> We cannot ignore alloca/malloc failures.
We generally ignore memory allocation errors of all kinds in the server
and APR. The general thought has always been that if you are act
On 2 Aug 2002 [EMAIL PROTECTED] wrote:
> +#ifdef WIN32
> +SOCKET fd;
> +#else
>int fd;
> +#endif
That's what apr_os_sock_t is for. Please use it instead of the ifdefs.
--Cliff
15 matches
Mail list logo
