Joe Orton wrote: > On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote: >> Paul Querna wrote: >>> Vote Results: >>> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson, >>> +1: Gregg Smith >>> +/-0: Rainer Jung >>> -1: William A. Rowe, Jr. >>> >>> Vote passes. >> I'm sorry. I explicitly insisted on a vote on the -deps package seperately >> from the 2.3.4 package, because it was entirely reasonable that Sander Temme, >> Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the >> httpd-2.3.4-alpha.tar.xx package alone. > > I've no issue at all with the -deps tarball containing a snapshot of > APR: > > 1) the httpd project cannot force the APR project to commit to API > stability by distributing a snapshot of the APR 1.4 branch. Why on > earth would that be the case? The only time the APR project commits to > API stability is by making a new .0 release itself. What other projects > do is irrelevant to APR. Joe, as I pointed out in another thread, httpd *does* commit apr the moment the mislabeled artifact hits www.apache.org/dist/ - where does that package suggest it is nothing but a snapshot? The answer is, it doesn't. When we did this previously in httpd 2.0 (never 2.1 to the best of my recollection) we actually did commit to that particular apr API. The rules in 0.9 just weren't so draconian. If you don't like any of these rules; * what is on /dist/ is a release * what is released apr >= 1.0 follows absolute versioning rules * what is a snapshot doesn't appear on /dist/ then take those issues to an infra/board level. We've had these discussions a thousand times on incubator lists, and this is a clear case of what is good for the goose... > 2) the httpd project isn't taking on any commitment to itself maintain > API stability in the shipped APR snapshot because *this is an alpha*, so > we're not guaranteeing API stability. Nope, much like broken ldap and crypto interfaces, it simply inflicts them upon apr and hopes for someone else to clean up the junk later, perhaps. But the apr project would be remiss in not voiding 1.4.x and moving on to 1.5.x for API additions since users can now be reasonably expected to have installed an apr 1.4.x major/minor with a specific feature set. > Furthermore I don't think it's a good idea to set a precedent of > requiring a separate vote on each file which makes up "the release". I > certainly presumed that the vote Paul called was for all the files > making up "the release". Nonsense. I post up httpd win32 binaries all the time to /dev/dist/. Do I really think everyone voting on the source code snapshot of httpd is paying any attention to that artifact (or this new -deps artifact, when all the deps are already provisioned on most voter's machines)?
Jeff Trawick wrote: > On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr. > >> As for broken versioning rules, please take that to APR. >> >> Perhaps in retrospect, APR would consider an even/odds approach as httpd >> has for adding (even eliminating) interfaces during a development cycle. > > IMO the determination could be as simple as whether or not a release > in the maj.min series has yet been declared GA. Not sufficient, IMHO, unless we add the appropriate indicators to allow feature tests in apr 2.0. E.g. the current test is VERSION_MAJOR >= 1 && VERSION_MINOR >= 4 and the APR versioning contract says that test is always sufficient. This dialog reads like folks may assume the httpd MMN feature tests work for APR functions, but there isn't such a feature test in APR.
Jeff Trawick wrote: > On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr. > <wrowe@rowe-clan.net> wrote: >> Jeff Trawick wrote: >>> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote: >>> >>>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the >>>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release >>>> forwards. >>> The APR versioning rules are hopelessly broken if a tarball snapshot >>> of the 1.4.x branch before a GA release casts the API in stone. >>> >>> Surely I misunderstood you. >> Is there a README indicating that the MAJOR/MINOR version tests for this >> particular tarball are not relevant/complete? No. >> >> This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release. >> You surely don't misunderstand what I said. > > Why is something with version x.y.z-dev a release and not a snapshot? Because snapshots don't live at http://www.apache.org/dist/, those are releases. The trigger didn't occur until Paul svn mv'ed it into there. Snapshots reside at http://svn.apache.org/snapshots/ >> As for broken versioning rules, please take that to APR. >> >> Perhaps in retrospect, APR would consider an even/odds approach as httpd >> has for adding (even eliminating) interfaces during a development cycle. > > IMO the determination could be as simple as whether or not a release > in the maj.min series has yet been declared GA.
On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote: > Jeff Trawick wrote: >> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote: >> >>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the >>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release >>> forwards. >> >> The APR versioning rules are hopelessly broken if a tarball snapshot >> of the 1.4.x branch before a GA release casts the API in stone. >> >> Surely I misunderstood you. > > Is there a README indicating that the MAJOR/MINOR version tests for this > particular tarball are not relevant/complete? No. > > This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release. > You surely don't misunderstand what I said. Why is something with version x.y.z-dev a release and not a snapshot? > As for broken versioning rules, please take that to APR. > > Perhaps in retrospect, APR would consider an even/odds approach as httpd > has for adding (even eliminating) interfaces during a development cycle. IMO the determination could be as simple as whether or not a release in the maj.min series has yet been declared GA.
Bojan Smojver wrote: > On Fri, 2009-12-04 at 07:52 +0100, Edgar Frank wrote: >> But after Grahams >> reply, I'm going to think about it twice. > > Yeah, if you're doing anything with APR and you pool lifetimes are not > clear, there will be trouble. What's interesting though, is that buckets were designed to transmorph from stack objects to pool when necessary. Although it costs a copy, shouldn't adding a bucket to another pool's brigade cause a copy?
On Fri, 2009-12-04 at 07:52 +0100, Edgar Frank wrote: > But after Grahams > reply, I'm going to think about it twice. Yeah, if you're doing anything with APR and you pool lifetimes are not clear, there will be trouble. -- Bojan
Bojan Smojver wrote: > Have you tried removing the buckets from the brigade with > APR_BUCKET_REMOVE() and then putting it in the second brigade? Yes, this was the way I tried. > As for copying buckets, once you read the contents of the > bucket into a standalone buffer, you can simply create a new > bucket from it and use that (i.e that would be the "deep" copy > of the bucket). This sounds reasonable in the first place. But after Grahams reply, I'm going to think about it twice. I'm not sure if I'm aware of all possible implications and if "deep" copying buckets is really the way to go for me. Thank you. Regards, Edgar
On 12/04/2009 05:38 AM, William A. Rowe Jr. wrote: > William A. Rowe Jr. wrote: >> Guenter Knauf wrote: >>> Hi, >>> William A. Rowe Jr. schrieb: >>>> I see good responses to the list from Branko, Joe and Jeff (and thanks >>>> for the bugfix Branko), so I'll proceed with this tonight, we'll have >>>> the usual 72hr vote, and then let's start this discussion over about >>>> the much larger changes in apr-util 1.4 ;) >>> I think we should take a look into the apr/apu tests first; Ruediger >>> mentioned this a while ago that we only report failures, but dont bail >>> out but instead try to use NULL pointers where we expect to have valid >>> pointers ...; therefore failing tests produce segfaults on some >>> platforms ... >> I don't see that as a showstopper to a major/minor bump; these are always >> bug fixes that can be addressed. >> >> What would be nice is if we could modify the test framework itself, perhaps >> fatal v.s. fail&continue flavors of all tests, to encourage the appropriate >> and proper logic in all test cases. > > Raises the question; are the contents of test/ subject to ABI, or only the > prototypes of include/* (nonrecursive)? > IMHO only include/* as I assume that no developer uses test/ in its own projects. IMHO test/ is only for internal APR / APR-UTIL purposes. Regards Rüdiger
William A. Rowe Jr. wrote: > Guenter Knauf wrote: >> Hi, >> William A. Rowe Jr. schrieb: >>> I see good responses to the list from Branko, Joe and Jeff (and thanks >>> for the bugfix Branko), so I'll proceed with this tonight, we'll have >>> the usual 72hr vote, and then let's start this discussion over about >>> the much larger changes in apr-util 1.4 ;) >> I think we should take a look into the apr/apu tests first; Ruediger >> mentioned this a while ago that we only report failures, but dont bail >> out but instead try to use NULL pointers where we expect to have valid >> pointers ...; therefore failing tests produce segfaults on some >> platforms ... > > I don't see that as a showstopper to a major/minor bump; these are always > bug fixes that can be addressed. > > What would be nice is if we could modify the test framework itself, perhaps > fatal v.s. fail&continue flavors of all tests, to encourage the appropriate > and proper logic in all test cases. Raises the question; are the contents of test/ subject to ABI, or only the prototypes of include/* (nonrecursive)?
Guenter Knauf wrote: > Hi, > William A. Rowe Jr. schrieb: >> I see good responses to the list from Branko, Joe and Jeff (and thanks >> for the bugfix Branko), so I'll proceed with this tonight, we'll have >> the usual 72hr vote, and then let's start this discussion over about >> the much larger changes in apr-util 1.4 ;) > I think we should take a look into the apr/apu tests first; Ruediger > mentioned this a while ago that we only report failures, but dont bail > out but instead try to use NULL pointers where we expect to have valid > pointers ...; therefore failing tests produce segfaults on some > platforms ... I don't see that as a showstopper to a major/minor bump; these are always bug fixes that can be addressed. What would be nice is if we could modify the test framework itself, perhaps fatal v.s. fail&continue flavors of all tests, to encourage the appropriate and proper logic in all test cases. But a segv to a test suite is usually a fail, so it's pretty unambiguous :)
Hi, William A. Rowe Jr. schrieb: > I see good responses to the list from Branko, Joe and Jeff (and thanks > for the bugfix Branko), so I'll proceed with this tonight, we'll have > the usual 72hr vote, and then let's start this discussion over about > the much larger changes in apr-util 1.4 ;) I think we should take a look into the apr/apu tests first; Ruediger mentioned this a while ago that we only report failures, but dont bail out but instead try to use NULL pointers where we expect to have valid pointers ...; therefore failing tests produce segfaults on some platforms ... Gün.
Paul Querna wrote: > > I don't agree that we can't release a bundled unreleased version of > APR, we did this for many versions of httpd 2.0.x and 2.1.x. It > definitely isn't preferred, but that's the APR project's problem. Look, your argument simply doesn't fly. In httpd 2.0 timeframe we were only shipping apr-0.9.x - it did NOT have the same API/ABI constraints (some of them, but not all). All of those intermediary releases kept the ABI rules of APR. Now that you have shipped immediately while ignoring my objection, I'll treat all +1's as binding no matter if they approved both of the pieces or not, and have tagged 1.4.0 of both apr and apr-util. We have no alternative, or else all author's VERSION_MAJOR/MINOR tests are invalid. It becomes up to the APR project if this aught to be 1.4.0 or burn a number and move on. For 1.4 initial release, I want to pick up Branko's fix, so I plan to label this 1.4.1. No intention of tagging apr-util yet till we decide if it can be API frozen, so if we dislike the current includes/ tree, it will end up being deprecated interfaces and version 1.5.0 already.
William A. Rowe Jr. wrote: > Folks, > > Please review the attached delta of apr 1.3 to 1.4 changes and > chime in if you believe we are ready to tag 1.4. I suspect we are. I see good responses to the list from Branko, Joe and Jeff (and thanks for the bugfix Branko), so I'll proceed with this tonight, we'll have the usual 72hr vote, and then let's start this discussion over about the much larger changes in apr-util 1.4 ;) Bill
Hello APR-developer, I'm new at this list and looking for some information about running apr on Win CE 5. I've found a patch from 2007, that isn't included in the latest release of apr (1.3.9). What is the actual situation regarding apr, apr-iconv and apr-util on Win CE? Has it already someone running? -- Kind regards Michael Augustin
Graham Leggett wrote: > As soon as I read this the first thing that leaped to mind was > "pool lifetimes". Thank you very much for your detailled reply. I thought I was aware of pool lifetimes before encountering this issue. What really surprised me was that if I put e.g. a heap bucket (as apr_brigade_split_line does) from one brigade into another, this couples these brigades in terms of pools and thread safety. In my opinion this creates a very dangerous situation in very harmlessly looking code and is really hard to debug if you don't know that you're up to. As I had race conditions instead of crashes, the APR_BUCKET_DEBUG and APR_RING_DEBUG macros could just bounce me a little bit into the right direction (by crashing sometimes instead of weird things happening). But as I was not aware of the problem, the stack traces left me clueless. I understand it now, but I think it would help people who are new to bucket brigades very much, if this behaviour would be clearly pointed out (personally preferred in code/doxygen doc). I could also think of special debug code to test such cases, but would imagine that this is really difficult to implement. By the way, I don't want to bother you with the full details of my problem unsolicited. If you're interested, just let me know. Regards, Edgar
Edgar Frank wrote: > I'm writing an Apache module which holds some number of > persistent connections to a backend server and hands them out to > each request (via an apr_reslist). The reslist holds sockes > and bucket brigades with a socket bucket in it (allocated on > the child pool). As soon as I read this the first thing that leaped to mind was "pool lifetimes". Bucket brigades are allocated from a pool, and your bucket brigade will be cleaned up when the pool is destroyed. There will be two pools you have to care about. The first pool belongs to the request, and is cleaned out when the request ends. The second pool you care about is the one that the reslist is handled from, and is likely to live for a very long time - definitely far longer than a request. If you accidentally refer to data allocated from the request pool, and place it into your reslist, that data will vanish when the request ends, and you will have dangling pointers and crashes. If you accidentally refer to data allocated from the reslist pool, and place it into your request, that data will vanish when the reslist is cleaned up, and if this happens during a request, that request will crash. What you need to ensure you do is respect the pool boundaries at all times. If two pools have completely unrelated lifetimes (as in this example), you need to be careful to copy data from the one pool into new memory allocated from the other pool. Alternatively if sockets are involved, you might dup the socket from the old pool to the new pool. While it may be tempting to just copy the buckets over, you'll doom yourself to all sorts of weirdness as the request dies unexpectedly, corrupting the reslist, or the reslist is reaped unexpectedly, corrupting the request. Regards, Graham --
On Thu, 2009-12-03 at 12:57 +0100, Edgar Frank wrote: > Regarding this and trying to work around the problem, I found no > possibility to decouple the two brigades. Have you tried removing the buckets from the brigade with APR_BUCKET_REMOVE() and then putting it in the second brigade? As for copying buckets, once you read the contents of the bucket into a standalone buffer, you can simply create a new bucket from it and use that (i.e that would be the "deep" copy of the bucket). -- Bojan
Hi list, I want to report an issue I encountered with bucket brigades. It's not really a bug - more some kind of complicated handling which is not documented. This mail might be a little lengthy, but I'd really appreciate if you could take the time to read and comment on this. My situation is as follows: I'm writing an Apache module which holds some number of persistent connections to a backend server and hands them out to each request (via an apr_reslist). The reslist holds sockes and bucket brigades with a socket bucket in it (allocated on the child pool). Now when I'm in a request and aquired a resource (socket + brigade) from the reslist, I read with apr_brigade_split_line from the brigade into a brigade allocated from the request pool. Afterwards, I return as soon as possible the resource back to the reslist to allow other requests to use the backend server. I guess you can already imaginge what happens next. I painfully found out by digging through the APU sourcecode. The bucket in the request-local brigade holds a reference to the original bucket of the brigade in the reslist, effectively messing with the ref-counter spuriously. What I complain about (no offense) is, that this is not documented. For someone who isn't deeply into the sourcecode, this is really frustrating, as one (IMHO) would expect that the two brigades are independent in terms of thread safety after a call to apr_brigade_split_line. My feedback for improvement would be to point these issues out in the documention. Regarding this and trying to work around the problem, I found no possibility to decouple the two brigades. Maybe I'm missining something, but as far as I see a copied bucket is still allocated on the source bucket_allocator. While I understand that ref-counting and cheap copying is crucial for performance, I'd also would like to see functions deep-copying buckets (as long as this is applicable - e.g. for heap buckets). If I just missed the function for this, I'd be glad if you could let me know. Regards, Edgar -- "Edgar Frank" <ef-lists@email.de>
Greetings, I know there had been several threads[1,2] somehow related to this which hadn't got any far but though would at least mention here that since the apr-1.3.8* packages are no longer in : http://www.apache.org/dist/apr/ then the download link that still has 1.3.8 on it as the last release is broken for all mirrors. Carlo [1] http://www.mail-archive.com/dev%40apr.apache.org/msg22273.html [2] http://www.mail-archive.com/dev%40apr.apache.org/msg22446.html
On Tue, Dec 1, 2009 at 4:01 AM, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote: > Folks, > > Please review the attached delta of apr 1.3 to 1.4 changes and > chime in if you believe we are ready to tag 1.4. I suspect we are. +1
On Tue, Dec 01, 2009 at 03:01:34AM -0600, William Rowe wrote: > Please review the attached delta of apr 1.3 to 1.4 changes and > chime in if you believe we are ready to tag 1.4. I suspect we are. Looks good here! Regards, Joe
William A. Rowe Jr. wrote:
> Folks,
>
> Please review the attached delta of apr 1.3 to 1.4 changes and
> chime in if you believe we are ready to tag 1.4. I suspect we are.
>
> Thanks!
>
>
Since there were no objections to the original trunk commit and
responses to my pings on-list, I merged r821306 from trunk to the 1.4
branch.
Index: CHANGES
===================================================================
--- CHANGES (revision 885698)
+++ CHANGES (revision 885699)
@@ -34,6 +34,9 @@
*) Add apr_file_link() function. PR 44841. [Mark Heily <mark heily.com>]
+ *) Win32: Properly handle the ERROR_DIRECTORY system error code.
+ [Brane ÄŒibej]
+
Changes for APR 1.3.x and later:
*) http://svn.apache.org/viewvc/apr/apr/branches/1.3.x/CHANGES?view=markup
Index: include/apr_errno.h
===================================================================
--- include/apr_errno.h (revision 885698)
+++ include/apr_errno.h (revision 885699)
@@ -1046,7 +1046,8 @@
|| (s) == APR_OS_START_SYSERR + ERROR_BAD_NETPATH \
|| (s) == APR_OS_START_SYSERR + ERROR_BAD_NET_NAME \
|| (s) == APR_OS_START_SYSERR + ERROR_BAD_PATHNAME \
- || (s) == APR_OS_START_SYSERR + ERROR_INVALID_DRIVE)
+ || (s) == APR_OS_START_SYSERR + ERROR_INVALID_DRIVE \
+ || (s) == APR_OS_START_SYSERR + ERROR_DIRECTORY)
#define APR_STATUS_IS_ENOSPC(s) ((s) == APR_ENOSPC \
|| (s) == APR_OS_START_SYSERR + ERROR_DISK_FULL)
#define APR_STATUS_IS_ENOMEM(s) ((s) == APR_ENOMEM \
Folks, Please review the attached delta of apr 1.3 to 1.4 changes and chime in if you believe we are ready to tag 1.4. I suspect we are. Thanks! Bill
+---------------------------------------------------------------------------+ | Bugzilla Bug ID | | +---------------------------------------------------------------------+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned | | | OPN=Reopened VER=Verified (Skipped Closed/Resolved) | | | +-----------------------------------------------------------------+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement TRV=Trivial | | | | +-------------------------------------------------------------+ | | | | Date Posted | | | | | +--------------------------------------------------+ | | | | | Description | | | | | | | |16056|Inf|Enh|2003-01-14|Shared memory & mutex ownership not correctly esta| |20382|New|Nor|2003-05-31|Poor performance on W2000 AS | |28453|New|Enh|2004-04-18|apr_uri should parse relative to a base URI | |33188|Inf|Nor|2005-01-21|libtool linking failure on Suse | |33490|Inf|Nor|2005-02-10|APR does not compile with Borland C++ | |38410|New|Nor|2006-01-27|apr/win32 misinterpreted the meaning of WAIT_ABAND| |39289|New|Enh|2006-04-12|test suite additions for trylock functions | |39853|Inf|Nor|2006-06-21|apr_strtoi64 does not build on WinCE due to lack o| |39895|New|Enh|2006-06-23|apr_os_strerror on WinCE needs to xlate unicode->u| |39896|New|Enh|2006-06-23|Output test status to OutputDebugString in additio| |40020|New|Enh|2006-07-11|Add support for apr_uint8_t and apr_int8_t types | |40193|Inf|Nor|2006-08-06|Patches to support different compiler than EMX on | |40622|New|Enh|2006-09-27|enhance apr temp files on NT to be more secure | |40758|Ver|Maj|2006-10-15|WIN64, apr_vformatter(..) cannot handle 64bit poin| |40939|New|Enh|2006-11-09|pool minimal allocation size should be configurabl| |41192|Inf|Trv|2006-12-17|Add the expat libtool file to the LT_LDFLAGS varia| |41254|New|Enh|2006-12-28|apr_queue_t enhancements | |41351|New|Enh|2007-01-11|Tivoli LDAP SDK support in aprutil | |41352|New|Min|2007-01-11|openldap and per-connection client certificates in| |41916|Inf|Nor|2007-03-21|MinGW support | |42365|New|Enh|2007-05-09|Suppress console for apr_proc_create() created pro| |42682|Ass|Maj|2007-06-17|Apache child terminates with signal 11 when using | |42728|New|Nor|2007-06-23|mod_ssl thread detaching not releasing handles | |42848|New|Enh|2007-07-10|add IP TOS support to apr_socket_opt_set() | |43035|New|Enh|2007-08-04|Add ability to wrap ssl around pre-existing socket| |43066|New|Nor|2007-08-08|get_password on Windows is kludgy | |43152|Inf|Nor|2007-08-16|apr_socket_opt_get doesn't work with APR_SO_SNDBUF| |43172|Ass|Nor|2007-08-20|apr-util don't want to find mozldap-6.x | |43217|New|Min|2007-08-26|All-ones IPv6 subnet mask not accepted | |43244|New|Enh|2007-08-29|apr_socket_t missing dup, dup2 and setaside | |43302|New|Nor|2007-09-04|apr_bucket_socket doesn't work with non-connected | |43309|New|Enh|2007-09-05|add apr_socket_sendtov support | |43375|Ass|Nor|2007-09-13|Pool integrity check fails for apr threads | |43499|New|Nor|2007-09-27|apr_global_mutex_create returns error "Access deni| |43507|New|Enh|2007-09-28|configure flag for SHELL_PATH | |43508|New|Enh|2007-09-28|Please be available whether atomics use thread mut| |43793|New|Enh|2007-11-04|builtin atomics on Windows | |44127|New|Enh|2007-12-21|File Extended Attributes Support | |44128|New|Enh|2007-12-21|apr_os_file_put() does not register a cleanup hand| |44129|New|Enh|2007-12-21|apr_os_dir_put() does not allocate an entry buffer| |44186|New|Nor|2008-01-08|[PATCH] Add memcached 1.2.4 features to apr_memcac| |44230|New|Enh|2008-01-14|Add Ark Linux support to config.layout | |44432|New|Enh|2008-02-15|patch - proposal for application function hooks | |44550|Inf|Maj|2008-03-06|Solaris sendfilev() handling - EINTR appears to ha| |44684|Inf|Nor|2008-03-26|32 libexpat used instead of 64 bit | |45232|New|Nor|2008-06-18|Empty APU_MODULES makes sh syntax error | |45251|New|Nor|2008-06-22|DBD MySQL driver doesn't support multiple resultse| |45256|New|Maj|2008-06-23|lack of object check for null value cause expectio| |45276|Opn|Nor|2008-06-25|Little issue with srclib/apr-util/Makefile | |45291|New|Nor|2008-06-26|apr_thread_t is leaking | |45298|New|Nor|2008-06-27|apr_os_thread_get() differs between windows and un| |45321|New|Nor|2008-07-01|Handling IPV6_V6ONLY on NT 5.x | |45407|Opn|Nor|2008-07-16|auto reconnect in apr_dbd_mysql disturb normal wor| |45455|New|Nor|2008-07-22|rwlock sometimes allows a writer to take the lock | |45496|New|Enh|2008-07-29|[patch] adding directory matching [dir/**/conf.d/*| |45650|New|Min|2008-08-19|Application reports "The entry point freeaddrinfo | |45700|New|Nor|2008-08-27|incorrect sort order of apr_strnatcmp with non-ASC| |45930|New|Nor|2008-10-01|httpd.worker MPM fails to reset signal mask before| |46029|New|Nor|2008-10-16|[httpd-2.2.10/srclib/apr/build/jlibtool.c:924]: Me| |46064|New|Nor|2008-10-22|apr_ldap_init call fails | |46175|New|Enh|2008-11-10|Full Mingw+MSys support | |46180|New|Nor|2008-11-10|apr_memcache_getp() returns value | |46181|New|Enh|2008-11-10|request feature: ability to connect to a socket un| |46205|New|Enh|2008-11-13|Extend apr_array with a function to shuffle member| |46233|New|Maj|2008-11-18|APR does not compile universal binaries on Mac OS | |46297|Opn|Enh|2008-11-25|apr_temp_dir_get should try /dev/shm in linux | |46389|New|Nor|2008-12-12|Datagram (UDP) broadcasts fail with "permission de| |46459|New|Enh|2008-12-31|apr_dbm BDB backend: allow db type selection | |46540|New|Nor|2009-01-15|apr_thread_pool support doesn't allow for apr_thre| |46799|New|Maj|2009-03-04|apr_thread_cond_create leaks handle (patch include| |46820|New|Nor|2009-03-08|[PATCH] apr_file_mtime_set working with symlinks | |46853|New|Nor|2009-03-13|utf8_to_unicode_path breaks .. and . expansion | |46937|Inf|Nor|2009-03-30|apr build error | |46964|New|Nor|2009-04-03|apr_sockaddr_vars_set() Needs to always set the po| |47044|New|Nor|2009-04-17|[Patch] apr_snprintf.c compile failure on AIX main| |47162|New|Enh|2009-05-06|[PATCH] crypto: read/write support for SSHA-1 (sal| |47181|New|Nor|2009-05-11|Fixes for MINT for apr library | |47191|New|Min|2009-05-13|Missing sentinel warning | |47258|Inf|Min|2009-05-24|Too many slashes with configure | |47441|New|Enh|2009-06-27|apr_hash: Allow custom key comparison function | |47471|New|Enh|2009-07-03|apr_hash: Implement apr_hash_set_if_new() | |47501|New|Maj|2009-07-09|[ldap] Setting LDAP_OPT_REFHOPLIMIT fails with Ope| |47572|New|Enh|2009-07-24|It would be nice if apr configure --with-dbm=xdbm | |47605|New|Enh|2009-07-29|apr-config: support for "--configure" | |47739|New|Nor|2009-08-26|Changes to apr_common.m4 file | |47776|New|Nor|2009-09-01|Change "apr_palloc / memcpy" to apr_pmemdup in APR| |47829|New|Min|2009-09-12|apr-config: CFLAGS should not include "-O2" | |47843|New|Cri|2009-09-15|Non-threadsafe use of memory pool by apr_thread_po| |47879|New|Enh|2009-09-20|add support for libiodbc (alternative to unixODBC)| |47891|New|Blk|2009-09-22|decision on anonymous shared memory allocation met| |47892|New|Cri|2009-09-23|configure: error: Could not detect suitable DSO im| |47931|New|Enh|2009-10-01|It is not possible to use CALL MySQL method with a| |47932|New|Enh|2009-10-01|apr_dbd_mysql: max_length field of MYSQL_FIELD st| |47974|New|Min|2009-10-09|srclib/apr/test/README - incorrect instructions | |47979|New|Min|2009-10-11|Installed pkg-config returns extraneous informatio| |48084|New|Nor|2009-10-29|Erasing HTTPD library global variables before rein| |48247|New|Cri|2009-11-20|Apache HTTP server could not respond HEAD message | |48298|New|Enh|2009-11-29|memcache UDP protocol support ? | +-----+---+---+----------+--------------------------------------------------+ | Total 98 bugs | +---------------------------------------------------------------------------+
On Tue, Nov 24, 2009 at 7:29 PM, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote: > apr-util, for purposes of 'trunk' forward development, has merged to the > trunk of apr/apr/ - there is only the single library as of 2.0.0-dev. Thank you. Probably this http://apr.apache.org/anonsvn.html page should be fixed then. -- Marko Kevac
Kevac Marko wrote: > Can you say something about lack of trunk in svn? > > On Tue, Nov 24, 2009 at 2:40 PM, Kevac Marko <marko@kevac.org> wrote: >> Seems there is no trunk there. >> >> [marko@marko-work distr]$ svn list http://svn.apache.org/repos/asf/apr/apr-util >> branches/ apr-util, for purposes of 'trunk' forward development, has merged to the trunk of apr/apr/ - there is only the single library as of 2.0.0-dev.
Can you say something about lack of trunk in svn? On Tue, Nov 24, 2009 at 2:40 PM, Kevac Marko <marko@kevac.org> wrote: > Seems there is no trunk there. > > [marko@marko-work distr]$ svn list http://svn.apache.org/repos/asf/apr/apr-util > branches/ > tags/ > > On Tue, Nov 24, 2009 at 2:24 PM, Kevac Marko <marko@kevac.org> wrote: >> By the way, what is working URL for svn trunk? URL which is on >> http://apr.apache.org does not work: >> >> [marko@marko-work distr]$ svn co >> http://svn.apache.org/repos/asf/apr/apr-util/trunk/ apr-util >> svn: URL 'http://svn.apache.org/repos/asf/apr/apr-util/trunk' doesn't exist > > -- > Marko Kevac > Sent from Moscow, Mow, Russia > -- Marko Kevac Sent from Moscow, Mow, Russia
On Tue, Nov 24, 2009 at 4:53 PM, Nick Kew <niq@apache.org> wrote: > A new bug in bugzilla, or repoen the existing one with a new patch. > (Have to confess, all I did before applying you patch was to verify > that the options it adds are documented in the MySQL manual). Reopened bug https://issues.apache.org/bugzilla/show_bug.cgi?id=48251 It's my fault. I send wrong patch and didn't noticed that :-( -- Marko Kevac Sent from Moscow, Mow, Russia
Kevac Marko wrote: > Unfortunately there is a bug in my patch. Not integer, but pointer to > integer should be sent to mysql_option() function. > > What is the right way to do now? > > Should I post patch against new trunk with bugfix, or should I post > patch without bug? A new bug in bugzilla, or repoen the existing one with a new patch. (Have to confess, all I did before applying you patch was to verify that the options it adds are documented in the MySQL manual). -- Nick Kew
Seems there is no trunk there. [marko@marko-work distr]$ svn list http://svn.apache.org/repos/asf/apr/apr-util branches/ tags/ On Tue, Nov 24, 2009 at 2:24 PM, Kevac Marko <marko@kevac.org> wrote: > By the way, what is working URL for svn trunk? URL which is on > http://apr.apache.org does not work: > > [marko@marko-work distr]$ svn co > http://svn.apache.org/repos/asf/apr/apr-util/trunk/ apr-util > svn: URL 'http://svn.apache.org/repos/asf/apr/apr-util/trunk' doesn't exist -- Marko Kevac Sent from Moscow, Mow, Russia
Unfortunately there is a bug in my patch. Not integer, but pointer to integer should be sent to mysql_option() function. What is the right way to do now? Should I post patch against new trunk with bugfix, or should I post patch without bug? By the way, what is working URL for svn trunk? URL which is on http://apr.apache.org does not work: [marko@marko-work distr]$ svn co http://svn.apache.org/repos/asf/apr/apr-util/trunk/ apr-util svn: URL 'http://svn.apache.org/repos/asf/apr/apr-util/trunk' doesn't exist And http://git.apache.org repos are not up to date as far as I can understand. On Fri, Nov 20, 2009 at 7:11 PM, Nick Kew <niq@apache.org> wrote: > Kevac Marko wrote: >> >> Â This patch adds connection, write and read timeout options for >> apr_dbd_mysql > > Thanks. > > Shouldn't the new options be inside the #if, to protect older MySQL > versions? > > -- > Nick Kew > -- Marko Kevac Sent from Moscow, Mow, Russia
Hi, The download page offers apr:: 1.3.8, apu:1.3.9 and api:1.2.1 the announce page says apr: 1.3.9. I know that 1.3.9 causes regression in Solaris could that explains the 1.3.8 in the download page? What about the 1.3.10? Should I fix the download page? Cheers Jean-Frederic
An error occured while fetching this message, sorry !
Jeff Trawick wrote: > > We need to release an alpha|beta 1.4.0-dev snapshot or two and ask not > just for implementation testing but also for feedback on new APIs > before they are frozen. While I wouldn't be totally surprised if we > get no useful API feedback from outsiders who don't follow this list, > the process should at least acknowledge the value of it. That sounds like a great idea, simply get the snapshots building and announce the API set-in-stone date for developers to comment. Bugs, they can be fixed whenever. Bad API design is our only regret.
On Thu, Nov 12, 2009 at 3:55 PM, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote: > William A. Rowe Jr. wrote: >> If nobody objects, I'll plan to tag 1.4.0 this coming Monday 11/16 > > ... unless somebody beats me to it, modulo the SHOWSTOPPERS in the > STATUS file. Unless crypto can be resolved to everyone's satisfaction, > and vetoes addressed, that means it may have to wait for 1.5/2.0. > But this is >1yr in discussion so holding our breath is futile, and > this is entirely unfair to the improvements offered by others which > have been universally accepted by the reviewers. > >> (it so happens to be after all my deadlines and right before more >> work obligations, so there a hole right there to fill). Should give >> anyone sufficient time to wrap up their inspection of the API and >> code changes. AFAICT we haven't discussed an alpha-or-beta/API-in-flux pre-1.4.0 tarball for widespread testing. The discussion seems to be along the lines of * developers get the API perfect (or yank out anything that isn't agreed upon yet) * tag & roll 1.4.0 (API cast in stone at this point) * vote whether 1.4.0 should be released, and if so whether alpha/beta/GA We need to release an alpha|beta 1.4.0-dev snapshot or two and ask not just for implementation testing but also for feedback on new APIs before they are frozen. While I wouldn't be totally surprised if we get no useful API feedback from outsiders who don't follow this list, the process should at least acknowledge the value of it.
APR_DECLARE(void) apr_global_mutex_names(apr_global_mutex_t *mutex,
const char **proc_mech,
const char **thread_mech)
{
*proc_mech = apr_proc_mutex_name(mutex->proc_mutex);
*thread_mech = NULL;
#if APR_HAS_THREADS
if (mutex->thread_mutex) {
*thread_mech = "pthread";
}
#endif
}
I'd like to be able to retrieve the selected mechanism(s) from a
global mutex like I can for a proc mutex, but somehow this is not a
very satisfying interface.
Also, Win32 and others wouldn't be able to
#define apr_global_mutex_names apr_proc_mutex_names
like they can for other global mutex functions.
--/--
Since thread mechanisms aren't configurable/selectable, there is
limited value in returning the name of the thread mechanism, so this
could just be
APR_DECLARE(const char *) apr_global_mutex_names(apr_global_mutex_t *mutex)
{
return apr_proc_mutex_name(mutex->proc_mutex);
}
and
#define apr_global_mutex_names apr_proc_mutex_names
--/--
Does anybody care? (Otherwise I'll go with the second choice and
explain away the issue of the potential, non-selectable second mutex
in the doc.)
+---------------------------------------------------------------------------+ | Bugzilla Bug ID | | +---------------------------------------------------------------------+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned | | | OPN=Reopened VER=Verified (Skipped Closed/Resolved) | | | +-----------------------------------------------------------------+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement TRV=Trivial | | | | +-------------------------------------------------------------+ | | | | Date Posted | | | | | +--------------------------------------------------+ | | | | | Description | | | | | | | |16056|Inf|Enh|2003-01-14|Shared memory & mutex ownership not correctly esta| |20382|New|Nor|2003-05-31|Poor performance on W2000 AS | |28453|New|Enh|2004-04-18|apr_uri should parse relative to a base URI | |33188|Inf|Nor|2005-01-21|libtool linking failure on Suse | |33490|Inf|Nor|2005-02-10|APR does not compile with Borland C++ | |38410|New|Nor|2006-01-27|apr/win32 misinterpreted the meaning of WAIT_ABAND| |39289|New|Enh|2006-04-12|test suite additions for trylock functions | |39853|Inf|Nor|2006-06-21|apr_strtoi64 does not build on WinCE due to lack o| |39895|New|Enh|2006-06-23|apr_os_strerror on WinCE needs to xlate unicode->u| |39896|New|Enh|2006-06-23|Output test status to OutputDebugString in additio| |40020|New|Enh|2006-07-11|Add support for apr_uint8_t and apr_int8_t types | |40193|Inf|Nor|2006-08-06|Patches to support different compiler than EMX on | |40622|New|Enh|2006-09-27|enhance apr temp files on NT to be more secure | |40758|Ver|Maj|2006-10-15|WIN64, apr_vformatter(..) cannot handle 64bit poin| |40939|New|Enh|2006-11-09|pool minimal allocation size should be configurabl| |41192|Inf|Trv|2006-12-17|Add the expat libtool file to the LT_LDFLAGS varia| |41254|New|Enh|2006-12-28|apr_queue_t enhancements | |41351|New|Enh|2007-01-11|Tivoli LDAP SDK support in aprutil | |41352|New|Min|2007-01-11|openldap and per-connection client certificates in| |41916|Inf|Nor|2007-03-21|MinGW support | |42365|New|Enh|2007-05-09|Suppress console for apr_proc_create() created pro| |42682|Ass|Maj|2007-06-17|Apache child terminates with signal 11 when using | |42728|New|Nor|2007-06-23|mod_ssl thread detaching not releasing handles | |42848|New|Enh|2007-07-10|add IP TOS support to apr_socket_opt_set() | |43035|New|Enh|2007-08-04|Add ability to wrap ssl around pre-existing socket| |43066|New|Nor|2007-08-08|get_password on Windows is kludgy | |43152|Inf|Nor|2007-08-16|apr_socket_opt_get doesn't work with APR_SO_SNDBUF| |43172|Ass|Nor|2007-08-20|apr-util don't want to find mozldap-6.x | |43217|New|Min|2007-08-26|All-ones IPv6 subnet mask not accepted | |43244|New|Enh|2007-08-29|apr_socket_t missing dup, dup2 and setaside | |43302|New|Nor|2007-09-04|apr_bucket_socket doesn't work with non-connected | |43309|New|Enh|2007-09-05|add apr_socket_sendtov support | |43375|Ass|Nor|2007-09-13|Pool integrity check fails for apr threads | |43499|New|Nor|2007-09-27|apr_global_mutex_create returns error "Access deni| |43507|New|Enh|2007-09-28|configure flag for SHELL_PATH | |43508|New|Enh|2007-09-28|Please be available whether atomics use thread mut| |43793|New|Enh|2007-11-04|builtin atomics on Windows | |44127|New|Enh|2007-12-21|File Extended Attributes Support | |44128|New|Enh|2007-12-21|apr_os_file_put() does not register a cleanup hand| |44129|New|Enh|2007-12-21|apr_os_dir_put() does not allocate an entry buffer| |44186|New|Nor|2008-01-08|[PATCH] Add memcached 1.2.4 features to apr_memcac| |44230|New|Enh|2008-01-14|Add Ark Linux support to config.layout | |44432|New|Enh|2008-02-15|patch - proposal for application function hooks | |44550|Inf|Maj|2008-03-06|Solaris sendfilev() handling - EINTR appears to ha| |44684|Inf|Nor|2008-03-26|32 libexpat used instead of 64 bit | |45232|New|Nor|2008-06-18|Empty APU_MODULES makes sh syntax error | |45251|New|Nor|2008-06-22|DBD MySQL driver doesn't support multiple resultse| |45256|New|Maj|2008-06-23|lack of object check for null value cause expectio| |45276|Opn|Nor|2008-06-25|Little issue with srclib/apr-util/Makefile | |45291|New|Nor|2008-06-26|apr_thread_t is leaking | |45298|New|Nor|2008-06-27|apr_os_thread_get() differs between windows and un| |45321|New|Nor|2008-07-01|Handling IPV6_V6ONLY on NT 5.x | |45407|Opn|Nor|2008-07-16|auto reconnect in apr_dbd_mysql disturb normal wor| |45455|New|Nor|2008-07-22|rwlock sometimes allows a writer to take the lock | |45496|New|Enh|2008-07-29|[patch] adding directory matching [dir/**/conf.d/*| |45650|New|Min|2008-08-19|Application reports "The entry point freeaddrinfo | |45700|New|Nor|2008-08-27|incorrect sort order of apr_strnatcmp with non-ASC| |45930|New|Nor|2008-10-01|httpd.worker MPM fails to reset signal mask before| |46029|New|Nor|2008-10-16|[httpd-2.2.10/srclib/apr/build/jlibtool.c:924]: Me| |46064|New|Nor|2008-10-22|apr_ldap_init call fails | |46175|New|Enh|2008-11-10|Full Mingw+MSys support | |46180|New|Nor|2008-11-10|apr_memcache_getp() returns value | |46181|New|Enh|2008-11-10|request feature: ability to connect to a socket un| |46205|New|Enh|2008-11-13|Extend apr_array with a function to shuffle member| |46233|New|Maj|2008-11-18|APR does not compile universal binaries on Mac OS | |46297|Opn|Enh|2008-11-25|apr_temp_dir_get should try /dev/shm in linux | |46389|New|Nor|2008-12-12|Datagram (UDP) broadcasts fail with "permission de| |46459|New|Enh|2008-12-31|apr_dbm BDB backend: allow db type selection | |46540|New|Nor|2009-01-15|apr_thread_pool support doesn't allow for apr_thre| |46799|New|Maj|2009-03-04|apr_thread_cond_create leaks handle (patch include| |46820|New|Nor|2009-03-08|[PATCH] apr_file_mtime_set working with symlinks | |46853|New|Nor|2009-03-13|utf8_to_unicode_path breaks .. and . expansion | |46937|Inf|Nor|2009-03-30|apr build error | |46964|New|Nor|2009-04-03|apr_sockaddr_vars_set() Needs to always set the po| |47044|New|Nor|2009-04-17|[Patch] apr_snprintf.c compile failure on AIX main| |47162|New|Enh|2009-05-06|[PATCH] crypto: read/write support for SSHA-1 (sal| |47181|New|Nor|2009-05-11|Fixes for MINT for apr library | |47191|New|Min|2009-05-13|Missing sentinel warning | |47258|Inf|Min|2009-05-24|Too many slashes with configure | |47441|New|Enh|2009-06-27|apr_hash: Allow custom key comparison function | |47471|New|Enh|2009-07-03|apr_hash: Implement apr_hash_set_if_new() | |47501|New|Maj|2009-07-09|[ldap] Setting LDAP_OPT_REFHOPLIMIT fails with Ope| |47572|New|Enh|2009-07-24|It would be nice if apr configure --with-dbm=xdbm | |47605|New|Enh|2009-07-29|apr-config: support for "--configure" | |47739|New|Nor|2009-08-26|Changes to apr_common.m4 file | |47776|New|Nor|2009-09-01|Change "apr_palloc / memcpy" to apr_pmemdup in APR| |47829|New|Min|2009-09-12|apr-config: CFLAGS should not include "-O2" | |47843|New|Cri|2009-09-15|Non-threadsafe use of memory pool by apr_thread_po| |47879|New|Enh|2009-09-20|add support for libiodbc (alternative to unixODBC)| |47891|New|Blk|2009-09-22|decision on anonymous shared memory allocation met| |47892|New|Cri|2009-09-23|configure: error: Could not detect suitable DSO im| |47931|New|Enh|2009-10-01|It is not possible to use CALL MySQL method with a| |47932|New|Enh|2009-10-01|apr_dbd_mysql: max_length field of MYSQL_FIELD st| |47974|New|Min|2009-10-09|srclib/apr/test/README - incorrect instructions | |47979|New|Min|2009-10-11|Installed pkg-config returns extraneous informatio| |48084|New|Nor|2009-10-29|Erasing HTTPD library global variables before rein| |48247|New|Cri|2009-11-20|Apache HTTP server could respond HEAD message unde| +-----+---+---+----------+--------------------------------------------------+ | Total 97 bugs | +---------------------------------------------------------------------------+
Hello While reading the generated docs I saw that a few descriptions are messed up. The cause is the use of @param in text instead of @a. Here's a log message and patch to fix this. Thanks, Martin PS: Please CC me, I'm not on the list. [[[ Replace @param by @a in doxygen texts. ]]] [[[ Index: include/apr_buckets.h =================================================================== --- include/apr_buckets.h (revision 883021) +++ include/apr_buckets.h (working copy) @@ -679,16 +679,16 @@ APR_DECLARE(apr_status_t) apr_brigade_cleanup(void *data); /** - * Move the buckets from the tail end of the existing brigade @param b into - * the brigade @param a. If @param a is NULL a new brigade is created. Buckets - * from @param e to the last bucket (inclusively) of brigade @param b are moved - * from @param b to the returned brigade @param a. + * Move the buckets from the tail end of the existing brigade @a b into + * the brigade @a a. If @a a is NULL a new brigade is created. Buckets + * from @a e to the last bucket (inclusively) of brigade @a b are moved + * from @a b to the returned brigade @a a. * @param b The brigade to split * @param e The first bucket to move * @param a The brigade which should be used for the result or NULL if * a new brigade should be created. - * @return The brigade supplied in @param a or a new one if @param a was NULL. - * @warning Note that this function allocates a new brigade if @param a is + * @return The brigade supplied in @a a or a new one if @a a was NULL. + * @warning Note that this function allocates a new brigade if @a a is * NULL so memory consumption should be carefully considered. */ APR_DECLARE(apr_bucket_brigade *) apr_brigade_split_ex(apr_bucket_brigade *b, @@ -698,8 +698,8 @@ /** * Create a new bucket brigade and move the buckets from the tail end * of an existing brigade into the new brigade. Buckets from - * @param e to the last bucket (inclusively) of brigade @param b - * are moved from @param b to the returned brigade. + * @param e to the last bucket (inclusively) of brigade @a b + * are moved from @a b to the returned brigade. * @param b The brigade to split * @param e The first bucket to move * @return The new brigade Index: include/apr_tables.h =================================================================== --- include/apr_tables.h (revision 883021) +++ include/apr_tables.h (working copy) @@ -364,11 +364,11 @@ * Iterate over a table running the provided function once for every * element in the table. The varargs array must be a list of zero or * more (char *) keys followed by a NULL pointer. If zero keys are - * given, the @param comp function will be invoked for every element + * given, the @a comp function will be invoked for every element * in the table. Otherwise, the function is invoked only for those * elements matching the keys specified. * - * If an invocation of the @param comp function returns zero, + * If an invocation of the @a comp function returns zero, * iteration will continue using the next specified key, if any. * * @param comp The function to run @@ -388,13 +388,13 @@ /** * Iterate over a table running the provided function once for every - * element in the table. The @param vp varargs parameter must be a + * element in the table. The @a vp varargs parameter must be a * list of zero or more (char *) keys followed by a NULL pointer. If - * zero keys are given, the @param comp function will be invoked for + * zero keys are given, the @a comp function will be invoked for * every element in the table. Otherwise, the function is invoked * only for those elements matching the keys specified. * - * If an invocation of the @param comp function returns zero, + * If an invocation of the @a comp function returns zero, * iteration will continue using the next specified key, if any. * * @param comp The function to run Index: include/apr_rmm.h =================================================================== --- include/apr_rmm.h (revision 883021) +++ include/apr_rmm.h (working copy) @@ -50,7 +50,7 @@ * @param membuf The block of relocatable memory to be managed * @param memsize The size of relocatable memory block to be managed * @param cont The pool to use for local storage and management - * @remark Both @param membuf and @param memsize must be aligned + * @remark Both @a membuf and @a memsize must be aligned * (for instance using APR_ALIGN_DEFAULT). */ APR_DECLARE(apr_status_t) apr_rmm_init(apr_rmm_t **rmm, apr_anylock_t *lock, Index: include/apr_hash.h =================================================================== --- include/apr_hash.h (revision 883021) +++ include/apr_hash.h (working copy) @@ -236,7 +236,7 @@ /** * Iterate over a hash table running the provided function once for every - * element in the hash table. The @param comp function will be invoked for + * element in the hash table. The @a comp function will be invoked for * every element in the hash table. * * @param comp The function to run Index: include/apr_network_io.h =================================================================== --- include/apr_network_io.h (revision 883021) +++ include/apr_network_io.h (working copy) @@ -553,9 +553,9 @@ /** * Read data from a socket. On success, the address of the peer from - * which the data was sent is copied into the @param from parameter, - * and the @param len parameter is updated to give the number of bytes - * written to @param buf. + * which the data was sent is copied into the @a from parameter, + * and the @a len parameter is updated to give the number of bytes + * written to @a buf. * @param from Updated with the address from which the data was received * @param sock The socket to use * @param flags The flags to use ]]]
Kevac Marko wrote: > On Fri, Nov 20, 2009 at 7:11 PM, Nick Kew <niq@apache.org> wrote: >> Thanks. >> >> Shouldn't the new options be inside the #if, to protect older MySQL >> versions? > > According to documentation page > (http://dev.mysql.com/doc/refman/4.1/en/mysql-options.html) no. These > options are there from the beginning. OK, well, it's done now, and I expect folks on the leading edge of APR will be using at least relatively-up-to-date MySQL. > Wow. Thank you for such fast answer and fast commit. > If only my other patches were committed so fast :-) There's an element of pot luck: whether you attract someone's attention at a good time. It also depends somewhat on how easy the patch is to review, whether it serves a purpose likely to be of general interest, etc. If you have patches languishing in bugzilla, it doesn't hurt to draw them to our attention: we might commit them, ignore them, rubbish them, or open a discussion on them :-) -- Nick Kew
On Fri, Nov 20, 2009 at 7:11 PM, Nick Kew <niq@apache.org> wrote: > Thanks. > > Shouldn't the new options be inside the #if, to protect older MySQL > versions? According to documentation page (http://dev.mysql.com/doc/refman/4.1/en/mysql-options.html) no. These options are there from the beginning. Wow. Thank you for such fast answer and fast commit. If only my other patches were committed so fast :-) -- Marko Kevac