RE: apr_pollset API

> No, they're the first 20 in the array. The result set only > contains signalled descriptors. Oops. I guess my brain was looking for a reason to quit what I was working on. Sorry for the noise. --rob

RE: [PATCH] pollacc.c poll.c

> >>Alternatively, we could compact the aprset array in > >>apr_poll_socket_remove(). This can be done in O(1) > >> > >> > > > >You can't do that because you don't own the apr_pollfd_t array, > management > >of the array is (now) the caller's responsiblity. > apr_poll_socket_remove() > >and kin ar

apr_pollset API

The pollset API seems to be missing something... create a pollset with size 100 add 50 descriptors call poll() If poll returns with 20 descriptors ready, I can't traverse the 20 ready descriptors because they're scattered over an array of 50. This means I have to traverse the whole 100 (wh

[PATCH] poll.c:apr_pollset_poll()

The descriptors return value for apr_pollset_poll() isn't setup in the !HAVE_POLL path.. --rob diff -u -r1.26 poll.c --- poll.c 4 Aug 2002 04:43:23 - 1.26 +++ poll.c 6 Aug 2002 01:18:17 - @@ -602,6 +624,7 @@ } } +*descriptors = pollset->result_set;

RE: [PATCH] pollacc.c poll.c

> I like the concept, but... > > >+else if (aprset[i].desc_type == APR_NO_DESC) { > >+pollset[i].fd = -1; > >+continue; > > > > I'm not sure if it's safe to have an fd of -1 in the pollset. I don't know if its portable but its the right approach on Solaris: If

[PATCH] apr_poll.h (choosing between the APIs)

The following patch incorporates Brian's and Ryan's comments regarding choosing between the two poll APIs. --rob Index: apr_poll.h === RCS file: /home/cvspublic/apr/include/apr_poll.h,v retrieving revision 1.5 diff -u -r1.5 apr_poll

[PATCH] apr_poll.h

The following patch to HEAD is suggested so that an empty apr_poll_t struct can safely be created by zeroing a chunk of memory. --rob Index: apr_poll.h === RCS file: /home/cvspublic/apr/include/apr_poll.h,v retrieving revision 1.5 d

[PATCH] pollacc.c poll.c

The following patch to HEAD corrects problems with the transparent poll API. Currently, the apr_poll_t struct is handled ambiguously WRT whether its entries are packed or sparse. The brokeness has probably not been apparent because in httpd entries are never removed. The HAVE_POLL path changes ar

RE: [PATCH] poll.c pollacc.c ab.c

> I applied part of your fixes [resolving the next issue.] That's the > problem with > submitting a patch of more than one issue... the net error issue was easy > for me to attack at the moment. OK.. New patches on the way. --rob

[PATCH] poll.c pollacc.c ab.c

Below are the updated patches I mentioned last night. They are the same as previously submitted (http://marc.theaimsgroup.com/?l=apr-dev&m=102721946317193&w=2, http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=102721825716797&w=2) but ported to HEAD. Its not clear to me which poll API should be

RE: New poll code

I posted a patch or two to ab to [EMAIL PROTECTED] a week or two back. At the time I didn't realize the poll code was in flux (but noticed shortly after). I actually have additional changes to submit but wanted to wait for the poll api to stablize. I'll bring it up to date and post it a little

apr-util/xml/expat/buildconf.sh

This change is required for apr-util/xml/expat/buildconf.sh as well. --rob > -Original Message- > From: Rob Saccoccio [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 23, 2002 8:13 AM > To: dev@apr.apache.org > Subject: [PATCH] apr/buildconf > > > A non-stand

[PATCH] apr/buildconf

A non-standard libtool installation tree confuses apr's buildconf. The 'cd $ltpath/../share/aclocal' fails because the dir doesn't exist. The approach below seems more reasonable. The '^datadir=' pattern is always present (>5yrs). I left the current approach in as a fallback. --rob diff -u -

[PATCH] poll/unix/poll.c & poll/unix/pollacc.c

I encountered some funk using ab on Win2K (patch to ab.c to follow on [EMAIL PROTECTED]). apr_poll() was returning errno without aprizing it or accounting for the WIN platform. apr_poll() didn't properly ignore pollset entries with a type of APR_NO_DESC. nsds is no longer setup on error. The HA

RE: [PATCH] apr/threadproc/win32/proc.c:apr_proc_create()

> And what was the side-effect of NULL handles to stdout/stderr > that you observed? That's what I've been trying to determine. Oh, sorry. There was no apparent side effect. The resulting process had stdout/stderr HANDLEs of 0 as one would expect. If they're not set to INVALID_HANDLE_VALUE the

RE: [PATCH] apr/threadproc/win32/proc.c:apr_proc_create()

> Um... -1 on committing this sort of code until I we have some explanation > of what problem the patch attempted to solve. There is a specific meaning > to NULL [default to the parent's handles] ... we need to know the behavior > problem Rob was experiencing. Yes, but STARTF_USESTDHANDLES was se

[PATCH] apr/threadproc/win32/proc.c:apr_proc_create()

The HANDLE members in the STARTUPINFO struct used in the call to CreateProcess() aren't currently initialized properly... --rob diff -u -r1.80 proc.c --- proc.c 5 Jul 2002 17:58:10 - 1.80 +++ proc.c 18 Jul 2002 04:31:54 - @@ -590,6 +590,10 @@ memset(&si, 0, siz