William A. Rowe, Jr. wrote:
Hmm,
testfile is fixed now, however testproc still fails with
testproc: \Line 68: expected 0, but saw 70014
-Line 143: expected 0, but saw 70014
This is apr-1.2 branch.
Are u seeing the same when running testall.exe -v?
Right. That's what I just said
Sorry for the spam, but all my mails are hitting the @apache except the apr
Just testing...
Mladen Turk wrote:
Sorry for the spam, but all my mails are hitting the @apache except the apr
Just testing...
OK. I'm trying to send the reply to the APR vote.
Let's try with the shortest message ...
OK, the second didn't pass as well, let's try even shorter one ...
apr-1.2-trunk
Mladen Turk wrote:
Hi. This is the qmail-send program at he-dc2-l2.avalon.hr.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
OK, I tried another SMTP but I still get the
Hi
Mladen Turk wrote:
Mladen Turk wrote:
Hi. This is the qmail-send program at he-dc2-l2.avalon.hr.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
OK, I tried another SMTP but I still get
William A. Rowe, Jr. wrote:
Please review and vote on those you have time to - reply once or four times,
just review those you can as you can; http://apr.apache.org/dev/dist/
+1/-1 Release
[-1] apr-1.2.10
Win .zip's will follow when I have a few minutes on a win box to extract
the
Hi,
The current pool logic always assure the
pool will be destroyed when it's parent is destroyed
(up to the global_pool singleton), and that's great, but ...
That presumption makes APR behaving badly in
threaded environment applications with its own memory
management because each time the
Paul Querna wrote:
Mladen Turk wrote:
Hi,
Looking at the apr_anylock.h, and the fact that its
totally independent of apr-util, can it be moved to apr?
From the end user perspective nothing would change,
because there can be no apr-util without apr, and apr
users would have those macros
Chris Darroch wrote:
But, before the cleanup function runs, apr_pool_destroy() will
have recursively called itself on all the sub-pools of the reslist's
pool, including all the sub-pools created by the constructor function.
Thus when the reslist's cleanup function runs and calls the
Hi,
Looking at the apr_anylock.h, and the fact that its
totally independent of apr-util, can it be moved to apr?
From the end user perspective nothing would change,
because there can be no apr-util without apr, and apr
users would have those macros without apr-util dependency.
Comments?
Colm MacCarthaigh wrote:
On Mon, Dec 11, 2006 at 02:58:04PM +0100, Mladen Turk wrote:
On WIN32, APR by default comes with IPV6 disabled.
I'm not sure what you mean by that. Do you mean the binary builds
particular developers make?
Yes and no. IPV6 on WIN32/WIN64 can be enabled only
Colm MacCarthaigh wrote:
So you are saying that the same API behaves differently
depending on the OS beneath. Then what's the purpose of the APR?
No, the API behaves no differently at all. The API deals with you
wanting to listen on the ANY just fine, on windows and so on it will
return ::
Colm MacCarthaigh wrote:
Are you sure?
Pass the NULL on unix enabled IPV6 APR, it will accept the
127.0.0.1. The IPV6 enabled Win32/Win64 will always reject this.
apr_sockaddr_t is a linked list, and you have to listen() on every
address in the list.
Look, I'm I speaking Marsian?
Same API
Colm MacCarthaigh wrote:
On Mon, Dec 11, 2006 at 04:48:23PM +0100, Mladen Turk wrote:
Colm MacCarthaigh wrote:
Are you sure?
Pass the NULL on unix enabled IPV6 APR, it will accept the
127.0.0.1. The IPV6 enabled Win32/Win64 will always reject this.
apr_sockaddr_t is a linked list, and you
Hi,
Enabling IPV6 gives a bunch of warnings:
multicast.c
./network_io/unix\multicast.c(206) : warning C4133: 'function' : incompatible
types - from 'struct ipv6_mreq *' to 'const char *'
./network_io/unix\multicast.c(240) : warning C4133: 'function' : incompatible
types - from 'unsigned int *'
William A. Rowe, Jr. wrote:
The apr-iconv issues go a bit deeper though - there is alot of warning noise
building apr-iconv on VC2005. It seems time to refresh those packages so that
users of the modern compiler can use it without incident.
There are also few warnings (like dozen) of them
[EMAIL PROTECTED] wrote:
Author: wrowe
Log:
Tagging 1.2.8
Wow, that's awesome!
Regards,
Mladen.
William A. Rowe, Jr. wrote:
Because this behavior breaks the API (do this in APR 1.2 and your code
will implode on 1.2.7) can we push this at 1.3.0?
It's for sure an 1.3 feature.
We would also need the portable APR_ prefixed flags when
calling recvfrom, like:
#define APR_MSG_PEEK MSG_PEEK
Jim Jagielski wrote:
I know that Bill is looking at a release of APR and
that alternate method would, I think, be better
implemented in APR than directly in httpd...
Eww, no thanks. AFAIK the same results can be achieved using existing
APR interfaces: a non-blocking apr_socket_recv()
Joe Orton wrote:
2) it's a really bad implementation. You can do the same thing portably
by doing a poll() and a recv(,MSG_PEEK) AFAICT. There is no need to
muck about with ioctls, and it can be done already without adding
anything to APR.
recv(, MSG_PEEK) is not portable, so its not
Hi,
It seems to me that only WIN32 platform actually uses apr-iconv.
All others platforms are dependent on system provided iconv library.
Further more the iconv 1.0 sources from Konstantin Chuguev that
originates from FreeBSD are way outdated and are not maintained
for years, so all the
Justin Erenkrantz wrote:
Create experimental branch for static (compiled-in) modules support.
What is this?
Simple code allowing to have some or all ccs/ces modules built in,
lowering down the amount of generated binaries and size.
Ideas need to be discussed on-list first and not just
Justin Erenkrantz wrote:
On 10/30/06, Mladen Turk [EMAIL PROTECTED] wrote:
I was not aware I made any mistake. IMHO, what I did is less
harmless then C-T-R/revert.
Or do you think I need to ask someone before every commit?
No, but when you create a branch, you should send an email explaining
Eric G wrote:
Hi,
I tried to use Apr win32 library tcnativa-1.dll I got from here
http://tomcat.heanet.ie/native/1.1.6/binaries/win32/.
This question is for Tomcat developers list
I used a very
simple java class to load the library, but I got the following exception:
Exception in
Hi,
Building APR gives a really strange binary sizes on Solaris.
$ gcc --version
gcc (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
Davi Arnaut wrote:
Debugging symbols ? other library linked statically (expat ?) ?
It's APR ./configure make make install
Have you tried to strip ?
No. Like said it's default build for APR.
If the strip is needed (what ever that might be,
so please share some light) then it should be
Joe Orton wrote:
On Wed, Oct 18, 2006 at 12:48:41PM +0200, Mladen Turk wrote:
Building APR gives a really strange binary sizes on Solaris.
...
produces the libapr-1.so.0.2.7 sized 3094060 bytes.
Debugging info, needs stripping (strip -x on Solaris IIRC).
Can this be done within the APR
Davi Arnaut wrote:
Could you please strip it and see what happens ? It won't hurt.
I don't have a strip on the box.
Where can I find that? Is that something custom, or it comes
in by default?
Regards,
Mladen.
Davi Arnaut wrote:
Could you please strip it and see what happens ? It won't hurt.
OK.
/usr/ccs/bin/strip -x libapr-1.so.0.2.7 resizes the .so
to the much 'normal' size of 170616 bytes from default 3M.
Can the reason for that be a -g compile switch?
If so, do you have any idea how to
Justin Erenkrantz wrote:
+1. We should stick with debug symbols by default.
So in general this relates to the windows .pdb files
embedded in the binary, correct? If so, then fine.
Those who are
doing binary releases can figure out how to run strip themselves...
The problem is that this
William A. Rowe, Jr. wrote:
David Horowitz wrote:
Would there be some way in APR to access the Windows Registry, and whatever
the analogs would be on other platforms?
The code already exists, but I didn't think it really fits into apr since
it's an 'anti-portability' feature :)
The Win32
William A. Rowe, Jr. wrote:
Ok - reading Mladen's and your comments, I'll agree the extra copy is
warrented, let's proceed on your plan...
* revert the original patch from 0.9, 1.2 branches for the moment
* let this patch settle a bit
* backport correct/complete patch
Or did I
Hi,
The current APR pool implementation destroys all child pools
before doing actual cleanup of registered objects.
I propose that we add the option that would mark the child pool
to be destroyed after all objects for that pool has been
destroyed.
Right now what we have on pool destroy/cleanup
Yann Rouillard wrote:
Hi,
I am currently having a strange problem when tomcat is used with apr.
The setup is tomcat 5.5.12, apr 1.2.7 on Solaris 10 on x86.
The question does not belong to this list.
See reply to your question at Tomcat users list.
Also, please do not cross post your
William A. Rowe, Jr. wrote:
Joe Orton wrote:
Yes - please do. One aspect of this patch I strongly dislike is the fact
that it's much less efficient. If the pool associated with the soon-to-be
allocated apr_socket_t would be destroyed on accept failure (the TYPICAL
design paradigm) there's no
Joe Orton wrote:
If the API guarantee is may allocate memory on failure then the fix is
bad and should be reverted; the caller will have to do the
create/destroy dance anyway so it's needless overhead whether large or
small.
This was the case without my patch to unix/sockets.c
I was will
Branko Čibej wrote:
William A. Rowe, Jr. wrote:
Branko Čibej wrote:
I'm attaching the threadpriv.c
Adding any of the '#pragma data_seg'
gives the following compile time warning for static
APR compiled for a simple hello-world.c:
MSVCRTD.lib(crtexe.obj) : warning LNK4078: multiple '.CRT'
Branko Čibej wrote:
Here's the code. This is the tss_pe.cpp file from Boost, slightly
modified (lines 35--37) in order to compile on Win/IA64. It compiles and
runs on x86, AMD64 and IA64, but I only ever tested it as a static
library.
Can you send some example of its usage?
Just send me
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Adding any of the '#pragma data_seg'
gives the following compile time warning for static
APR compiled for a simple hello-world.c:
MSVCRTD.lib(crtexe.obj) : warning LNK4078: multiple '.CRT' sections
found with different attributes (40400040
Greg Marr wrote:
At 12:06 PM 9/15/2006, William A. Rowe, Jr. wrote:
Quick observation, but MSVCRTD.lib in combination with VS 2005?
Yes, the lib file does not have the version number in the filename.
???
What are you talking about?
--
Mladen.
Greg Marr wrote:
At 12:59 PM 9/15/2006, Mladen Turk wrote:
Greg Marr wrote:
At 12:06 PM 9/15/2006, William A. Rowe, Jr. wrote:
Quick observation, but MSVCRTD.lib in combination with VS 2005?
Yes, the lib file does not have the version number in the filename.
???
What are you talking about
William A. Rowe, Jr. wrote:
I'm still -1 on that approach, for the very reason that it doesn't
produce any consistent results. I'm not arguing that your solution
isn't a partial answer to the fact that we get -no- results today, but
I'm arguing that the right solution beats half a solution.
Henry Jen wrote:
Justin Erenkrantz wrote:
In short, there's no way to portably detect the socket is closed via a
poll()-like mechanism. It seems like everyone keeps running into
this. Apparently, the only way to know if it is closed is to read()
from it - which really sucks. -- justin
If
Jeff Trawick wrote:
Occasionally I see problems caused by Apache modules using per-process
pools on a request processing thread. Aside from the thread-safety
issues, they had no business doing that anyway.
apr_pool_lock() - cause abort() on subsequent allocation request
apr_pool_unlock() -
Branko Čibej wrote:
Mladen Turk wrote:
MSVCRTD.lib(crtexe.obj) : warning LNK4078: multiple '.CRT' sections
found with different attributes (40400040)
MSVCRTD.lib(cinitexe.obj) : warning LNK4254: section '.CRT' (C040)
merged into '.rdata' (4040) with different attributes
William A. Rowe, Jr. wrote:
I thought the concensus was that the MSVC's own destructor callbacks
were more interesting, since they would permit apr to be statically
bound to the app?
I have tried the think Brane mentioned.
Even contacted the original author of the article
from Codeguru (Jac
Branko Čibej wrote:
I know that boost_thread uses this method, and I've verified that it
works on AMD64 and IA64; the tric is, I believe, that Boost inserts a
single static handler into the static constructor and destructor
segments, and lets that handler maintain its own list of hooks.
Here
Branko Čibej wrote:
I know that boost_thread uses this method, and I've verified that it
works on AMD64 and IA64; the tric is, I believe, that Boost inserts a
single static handler into the static constructor and destructor
segments, and lets that handler maintain its own list of hooks.
Well
William A. Rowe, Jr. wrote:
I thought the concensus was that the MSVC's own destructor callbacks
were more interesting, since they would permit apr to be statically
bound to the app?
I would really like to see the code Brane mentioned.
On that note, doesn't this patch break if you
Hi,
I would like to backport the threadkey
destructor functionality from trunk to 1.2
Is some backport vote required like for httpd,
or can I simply commit my patches, since they
don't change the API in any way.
Regards,
Mladen.
Take 2 for the PATCH that uses hash table instead
fixed size struct.
This cause that init and terminate functions has been
moved to the apr_initialize/terminate because of
pool needed for construction table.
Comments?
--
Mladen.
Index: misc/win32/start.c
Garrett Rooney wrote:
On 8/23/06, Mladen Turk [EMAIL PROTECTED] wrote:
A few on the actual code:
- if (env) {
+if (env) {
Right, its a Tab police.
If this hash is going to be non-static and shared among modules it
needs to be properly prefixed. apr_tls_threadkeys
Hi,
pthreads have option to register destruct callback
for private thread keys created.
Here is the patch that allow that for WIN32 but
only when compiled as dll.
Any comments or objections?
The consequence is that the DllMain is added, and
I suppose its not possible to have that functionality
Garrett Rooney wrote:
On 8/21/06, Mladen Turk [EMAIL PROTECTED] wrote:
One comment, where did the number 1088 come from? Should probably
replace it with a #define or something in any event.
1088 comes from the MSDN:
The constant TLS_MINIMUM_AVAILABLE defines the minimum number of TLS
Garrett Rooney wrote:
On 8/21/06, Mladen Turk [EMAIL PROTECTED] wrote:
Garrett Rooney wrote:
On 8/21/06, Mladen Turk [EMAIL PROTECTED] wrote:
One comment, where did the number 1088 come from? Should probably
replace it with a #define or something in any event.
1088 comes from the MSDN
Garrett Rooney wrote:
Sure, we can have #define WHAT_EVER 1088, but it would
have no relation to the MSDN.
Fine, just stick a comment next to it saying we set WHAT_EVER to 1088
because that's the largest value currently used for the minimum number
of TLS indices on current versions of Windows
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
William A. Rowe, Jr. wrote:
I had a similar issue with this proposal, and came to a different possible
solution ... we could run the destructors as part of the thread return
processing from our apr thread start function when the thread returns
Ruediger Pluem wrote:
Reposting what I sent to Mladen in private. Just missed that
his address was in to and not dev@apr.apache.org :-)
OK. Here is the new code used in mod_jk
It works for the selected set of platforms
(windows, linux, solaris)
Any comments about other platforms?
int
Hi,
We have a problem with mod_proxy and
the way how we detect if the connection is
still opened.
Right now, the algorithm for that is as follows:
1. Remember socket timeout
2. Set timeout to 0
3. Try to read one byte
4. Restore timeout
6. If read is APR_STATUS_IS_EOF return False
5. Else
Joe Orton wrote:
On Wed, Aug 02, 2006 at 01:42:52PM +0200, Mladen Turk wrote:
We have a problem with mod_proxy and the way how we detect if the
connection is still opened.
Polling the socket is all you can do, but all that tells you is whether
the local end of the TCP socket has already
William A. Rowe, Jr. wrote:
APR-util library:
Source Location http://svn.apache.org/repos/asf/apr/apr-util/trunk
Includes the optional(1) use of the OpenSSL Cryptographic library
to SSL encrypte socket communication using the apr_ssl_socket API.
???
Can you point
Hi,
I propose a new function apr_poll_modify, or
modifying apr_poll_add to be able to change
the interest ops/events for a designated apr_pollfd_t.
The point is to have an option to modify the
request events (poll options) without the need
to remove/add the same socket with different reqevents.
William A. Rowe, Jr. wrote:
-1 veto. Please revert.
Reverted.
Installed (finalized) c language headers cannot be volitile based on
environmental factors. It's the #1 source of my wasted time (not in ASF
projects, specificially).
Correct if you need to have installed headers files with
William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
Shall we set up an appropriate perl/python/awk script which accepts
--with-iconv and can direct it at apr-iconv, libiconv for the gnuish
folk or something else altogether?
Of course --without-iconv is one of those legitimate
William A. Rowe, Jr. wrote:
I think we can have a simple .vbs or .js script.
Using other languages is additional tool dependency thought.
I know :(
I'm almost resigned to saying something like, users who build APR have
.NET 1.0 or bigger installed, so just write the danged things in C#.
I
Hi,
Here is the proposed patch for WIN32 that will like
epoll favor the APR_POLLHUP pollset_poll events when the
socket has been closed.
It uses additional WSAEVENT event record that is
created if APR_POOLHUP or APR_POOLPRI is specified
as reqevent.
Application that polls the accepted socket
Hi,
What do you guys think of this email subject?
IMHO it would make an additional requirement
for the unix builds of httpd, but windows is
dependent on it anyhow.
OTOH, the xlate would go to it's proper place,
because it is a part of apr-iconv.
The reason is simple. If someone needs xlate
Garrett Rooney wrote:
From the users point of view noting will change, except that
the apr_xlate will reside in a different .so.
In that case I still think it's a bad idea, there's no change other
than requiring those users to download a huge amount of code they
don't actually need because
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
OTOH, the xlate would go to it's proper place,
because it is a part of apr-iconv.
Nope, you got it entirely upside down.
apr_xlate is a simple (not quite simple enough) interface for encoding
translations. If it's via iconv, or libiconv
William A. Rowe, Jr. wrote:
Mladen, perhaps I failed to make my point below. *Today* you can build
your
very own apr for your app with whatever features enabled/crippled that
you like.
The point is not in the apr, but rather in the apr-util.
The fact IS that the apr-util IS dependent on
Nick Kew wrote:
We have a requirement for a new backend to mod_dav.
It seems to me that this could work well with the APVFS architecture,
reducing the job to developing a new driver for APVFS. But APVFS
is marked at sourceforge as pre-alpha and doesn't look like a
thriving community.
Is there
Garrett Rooney wrote:
On 3/23/06, Justin Erenkrantz [EMAIL PROTECTED] wrote:
On 3/23/06, Garrett Rooney [EMAIL PROTECTED] wrote:
Ok, we've got various Unices (Linux, FreeBSD, Solaris), and Netware
covered pretty well. Any chance of a Win32 person being able to take
this stuff for a spin and
Paul Querna wrote:
Tarballs of APR 1.2.5 are available for testing voting from:
http://people.apache.org/~pquerna/dev/apr-1.2.5/
+1 (WIN32 and WIN64)
--
Mladen.
Sean Neeley wrote:
I’m using APR 1.2.2 with Tomcat 5.5.15. Occasionally I need to restart
the JVM, and so I have one of my servlets call System.exit(0). When
using the APR libraries with tomcat, exiting the JVM in this manor
leaves port 8009 in the FIN_WAIT2 state (see netstat man page).
Garrett Rooney wrote:
URL: http://svn.apache.org/viewcvs?rev=368769view=rev
Log:
Mark pool param for apr_file_remove and apr_file_rename
as unused (because it is).
Perhaps some day it will be removed from the API.
I'm not sure how I feel about this. The pool could potentially be
used for
William A. Rowe, Jr. wrote:
Chris Storah wrote:
Enclosed is a patch to fix a leak in APR threads, due to _endthreadex
not automatically closing the handle (unlike _endthread).
Chris,
this is facinating, thank you for bringing it to our attention!!!
There are couple of more things:
1.
Colm MacCarthaigh wrote:
I'd like to turn the svn:eol-style attribute off for the windown build
files (files ending in .dsp, .dsw and win32ver.awk), and have them
stored in win32 new-line format in the repository.
Any objections?
I'm not sure you can use the .dsw and .dsp file outside
Hi all,
Since apr-util mostly contains third-party libraries
wrappers, and some code completely independent of any
platform, I propose that we move that independent code
from apr-util to apr, and since the API itself won't
change it will not bring any build problems for
apr/apr-util based
Garrett Rooney wrote:
On 10/24/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
If you are trying to avoid 3rd party library dependencies on db, xml, ldap
and so on, perhaps we can make this code less fragile, or not require so
many bindings when that code is not referenced by an
Nick Kew wrote:
William A. Rowe, Jr. wrote:
The *right* thing to do in httpd2.2 is probably quit loading global,
since we getsym the module structure, and launch everything from
there. Perhaps, if a user needs all the symbols, they can use
LoadFile to obtain those.
LoadModule foo_modules
Hi,
Anyone knows if there is a possibility to create a .so that
will use APR as static library?
Also what will happen if I have a multiple .so's inside the
same process each with APR statically linked.
Is something like that possible?
Regards,
Mladen.
Paul Querna wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Good Afternoon,
APR 1.2.0 is ready for testing and voting for release.
+1.
Tested on WINXP/i386, WINXP/amd64, SLES9/amd64
Regards,
Mladen.
Paul Querna wrote:
[EMAIL PROTECTED] wrote:
I dont suppose anyone has
compiled the newer APR-Util DBD code on windows yet?
Well, it compiles fine, but seems that it needs three
additional projects for each driver .dll correct?
Anyhow, I'll add the apr_dbd.c to the apr-util .dsp's.
Actual
William A. Rowe, Jr. wrote:
Let's not create a half dozen dbd .dsp flavors.
Right.
Seems I've overlooked the fact that the basic 'provided'
drivers can be used in static mode.
Anyhow, I've added all apr_dbd_* to the windows build.
I have even tried to enable the SQLITE3 and it works
William A. Rowe, Jr. wrote:
Mladen;
I'd prefer you don't commit this, *yet*.
Well, like said didn't had any intention to commit anything
before some consensus :)
Question; do we want to adopt (finish adopting) svn's build
system coded in python?
Are you guys saying that I would need a
William A. Rowe, Jr. wrote:
At 12:27 PM 6/28/2005, Mladen Turk wrote:
Are you guys saying that I would need a python to even
consider to build a APR from the cvs/svn?
This is true *today* for everyone except Win32 (and netware?)
Yes, but why?
What does a gen-build.py offers that can
CFLAGS
# CPPFLAGS Added to the common CPPFLAGS
# LIBS Added to the common LIBS
# INCLUDES Added to the common INCLUDES
#
# Originally contributed by Mladen Turk mturk jboss.com
Hi,
Can we move the entire apr_xlate API from apr-utils to
the apr-iconv?
Reason for that is quite simple:
You can have apr-util independent from apr-iconv.
Thoughts?
Regards,
Mladen.
Jeff Trawick wrote:
Can we move the entire apr_xlate API from apr-utils to
the apr-iconv?
no; apr_xlate works just fine without apr-iconv (when system provides
a suitable iconv)
It does not.
On some platforms (WIN32) you can not build apr-util without apr-iconv.
At least this is a
Jeff Trawick wrote:
On 5/30/05, Mladen Turk [EMAIL PROTECTED] wrote:
Of course the other option is to disable apr_xlate by default if
either iconv or apr-iconv is not found.
What is the problem to solve here?
a) apr-util doesn't guarantee that all APIs are present on all builds
of APR
b
Jeff Trawick wrote:
Can we move the entire apr_xlate API from apr-utils to
the apr-iconv?
no; apr_xlate works just fine without apr-iconv (when system provides
a suitable iconv)
It does not.
you misread my statement, but that isn't really the point... (I was
trying to convince you that
Hi,
Untill multicast support for WIN32 gets enabled, can we
add it to the build, so that at least APR_ENOTIMPL is returned.
Any objections?
Regards,
Mladen.
Hi,
Until multicast support for WIN32 gets enabled, can we
add it to the build, so that at least APR_ENOTIMPL is returned.
Any objections?
Regards,
Mladen.
Bill Stoddard wrote:
William A. Rowe, Jr. wrote:
This makes alot of sense. But we are talking about the need for
large scale parallelism, not discrete events. Once a given unit
of I/O work can be performed on a given socket or pipe, it's going
to be time to farm it out to a worker.
If I
William A. Rowe, Jr. wrote:
IIUC - there are -very- few cases where you need a massive
array of poll/select objects, because in most cases it's not
practical with a threaded architecture.
Cases in point; the httpd listen pool, the jni listen pool.
Any other good examples?
We are using it
Hi,
Since the WIN32 imposes pretty nasty limit on FD_SETSIZE to 64, that
is way too low for any serious usage, I developed an alternative
implementation.
Also the code support the APR_POLLSET_THREADSAFE flag.
A simple patch to apr_arch_poll_private.h allows to have
multiple implementations
Paul Querna wrote:
LPCRITICAL_SECTION mutex;
Why can't this be an apr_thread_mutex?
It's the same thing.
Hmm. I am not really happy with this loop. I don't think this will be
very fast with thousands of Sockets. I am far from an expert on Win32,
but why can't 'WSAWaitForMultipleEvents' be
William A. Rowe, Jr. wrote:
I do have a productive suggestion though that we kicked around once or
twice. Spin up helper threads (we can even keep a cache of them) to
handle each group of 64 events, and have them pop an event to the
parent thread once finished. at 64x63 events, this could be
William A. Rowe, Jr. wrote:
Feel free to research; the issue is the underlying calls to
[WSA]WaitForEventOrTimeout ... Windows can't poll more than
64 handles + timeout event.
Well, I have tested by precompiling the APR with FD_SETSIZE set
to 16384, and didn't find any issues.
Actually it can poll
Hi,
Can we set the FD_SETSIZE to a higher number then 64
on Windows platform?
Here is what docs say:
The default value of FD_SETSIZE is 64, which can be modified by defining
FD_SETSIZE to another value before including Winsock2.h
So, I'd like that we define the FD_SETSIZE to a 1024, like its
201 - 300 of 416 matches
Mail list logo
