Re: Move apr_xlate from apr-util to apr-iconv?
No true. apr_xlate API is used in more places than just EBCDIC. Mod_auth_ldap uses it to translate user names to UTF-8 before passing it to the LDAP server. mod_charset_lite uses it to map charsets from one to another before send output to the browser. This is extremely useful on the NetWare platform when dealing with directory and file listings. BTW, the NetWare platform also has a suitable iconv which means that apr-util builds without any dependancy on apr-iconv as well. Brad Mladen Turk [EMAIL PROTECTED] Monday, May 30, 2005 12:10:09 PM 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 the current arrangement makes a lot of sense on some platforms...) I just browse the source code for the httpd and in 99% there is a single need for apr_xlate API, and that is to convert from ISO-8859-1 to EBCDIC if someone is using IBM at the first place. So IMHO we can write a simple converter for that, and get rid entirely of iconv dependency from apr-util. Someting like apr_ascii_to_ebcdic should do thought. If someone wish to use the translation mechanism, well, the there is apr-icov project that should in that case provide the full apr_xlate api. Only mod_charset_lite uses the full capability of iconv stuff, so what's the point to link the apr-util with the iconv/apr-iconv anyhow? Regards, Mladen.
confusion about largefile support
[Posting to both apr and subversion dev lists.] I know that largefile support is kludgey in APR 0.9x, but unfortunately, thousands of Subversion users are still using that branch (and httpd 2.0.x) because of the binary compatibility issue. Someone privately pointed out to me today that Subversion isn't passing the APR_LARGEFILE flag to *any* apr_file_io calls anywhere. Are we sitting on time bomb? (Subversion issue 1819 (http://subversion.tigris.org/issues/ show_bug.cgi?id=1819) discusses some problems we had with apr_file_copy(), but we worked around it by writing our own copy implementation that doesn't use offsets.) We've not seen any issues reported, but something came into our users@ list over the weekend. A woman was doing an 'svnadmin load' of a large dumpfile into an FSFS repository, and got this error: Started new transaction, based on original revision 1046 * adding path : trunk/some folder ... done. * adding path : trunk/some folder/some_file.zip ...File size limit exceeded. The phrase File size limit exceeded comes from libc, so now I'm wondering if the largefile flag is the problem here. Perhaps the fsfs revision file is 2GB, and apr_file_open() is tripping over it? (This woman is using the Fedora 3 apr-0.9.4-24.2 rpm, by the way.) In any case: I'm wondering if we should be passing APR_LARGEFILE to all apr_file_io calls. Is it necessary? Should we expect problems if we don't? Here's a link to the original [EMAIL PROTECTED] thread: http://svn.haxx.se/users/archive-2005-05/1801.shtml
Re: confusion about largefile support
On Tue, 2005-05-31 at 11:18 -0500, Ben Collins-Sussman wrote: In any case: I'm wondering if we should be passing APR_LARGEFILE to all apr_file_io calls. Is it necessary? Should we expect problems if we don't? Passing APR_LARGEFILE does not magically change the size of apr_off_t; it does not gain us the ability to seek around in 2GB files. It's essentially a promise to APR that we don't need to seek, so it's okay to go above the 2GB limit. However, we most definitely do need to seek around in FSFS rev files, which are the most common thing to go above 2GB. APR_LARGEFILE won't help us for that case.
Re: confusion about largefile support
On Tue, 2005-05-31 at 11:49 -0500, Ben Collins-Sussman wrote: Okay, so then there really is a risk here for very large repositories, particularly ones using FSFS. It doesn't matter how large the repository is, only how large the commits to it are. Should we start recommending that such projects upgrade to APR 1.X (and httpd 2.1, if they're depending on mod_dav_svn?) Should we write a FAQ about it? There's no particularly strong reason not to wait until you have a problem or are likely to have a problem before going to such lengths. Funny, KDE is using fsfs, and I would have expected them to run into a 2GB revision file. Why would a KDE developer commit more than 2GB of changes in one go?
Re: confusion about largefile support
On May 31, 2005, at 11:45 AM, Greg Hudson wrote: However, we most definitely do need to seek around in FSFS rev files, which are the most common thing to go above 2GB. APR_LARGEFILE won't help us for that case. Okay, so then there really is a risk here for very large repositories, particularly ones using FSFS. Should we start recommending that such projects upgrade to APR 1.X (and httpd 2.1, if they're depending on mod_dav_svn?) Should we write a FAQ about it? Funny, KDE is using fsfs, and I would have expected them to run into a 2GB revision file.
Re: svn commit: r178386 - /apr/apr/trunk/build/apr_hints.m4
Joe- I think you're right and that there is some busy-waiting going on. Though the behavior is legal API-wise, it looks sub-optimal. Given that, disabling poll until there is a kernel without that problem seems prudent. I'll go ahead and do that later today and do that if no one objects. -wsv On May 25, 2005, at 2:36 PM, Joe Orton wrote: On Wed, May 25, 2005 at 11:49:25AM -0700, Wilfredo Sánchez Vega wrote: I just fixed APR to retry on EAGAIN. We should not disable the use of poll() on Darwin. It's behavior on 10.4 may be unusual, but it has not been shown to be broken. It's right for older versions still in any case; please fix it omit 10.4 if you're really sure that's right, I can't guess a pattern to match the appropriate versions. Your change needs backporting to all the branches, too. The fact that Al is triggering this behaviour so easily leaves me entirely unconvinced that this is a happy poll implementation, however. Is APR now busy-waiting in the poll/send loop for Al, have you checked a system call trace? Have you run the APR test suite on it, too? joe smime.p7s Description: S/MIME cryptographic signature
Missing WaitForSingleObject on apr_thread_cont's mutex?
Hi,
I was looking at the apr_thread_cond.c, and wondering if the
apr_thread_cond_wait apr_thread_cond_timedwait code is missing a
WaitForSingleObject call on the mutex. Would someone share some light
with me? :-)
The following is code snippet from the SVN trunk, and it seems to be
same as in apr-0.9.6. Comments in the code.
Cheers,
--
Henry Jen aka slowhog
http://blogs.sun.com/slowhog
APR_DECLARE(apr_status_t) apr_thread_cond_wait(apr_thread_cond_t *cond,
apr_thread_mutex_t *mutex)
{
DWORD res;
while (1) {
res = WaitForSingleObject(cond-mutex, INFINITE);
if (res != WAIT_OBJECT_0) {
return apr_get_os_error();
}
cond-num_waiting++;
/* cond-mutec had been released here */
ReleaseMutex(cond-mutex);
apr_thread_mutex_unlock(mutex);
res = WaitForSingleObject(cond-event, INFINITE);
/* should we add a mutex lock here to protect num_waiting value? */
/* WaitForSingleObject(cond-mutex, INFINITE); */
cond-num_waiting--;
if (res != WAIT_OBJECT_0) {
apr_status_t rv = apr_get_os_error();
/* Aren't we releasing a mutex without locking it first? */
ReleaseMutex(cond-mutex);
return rv;
}
if (cond-signal_all) {
if (cond-num_waiting == 0) {
ResetEvent(cond-event);
}
break;
}
if (cond-signalled) {
cond-signalled = 0;
ResetEvent(cond-event);
break;
}
/* Aren't we releasing a mutex without locking it first? */
ReleaseMutex(cond-mutex);
}
apr_thread_mutex_lock(mutex);
return APR_SUCCESS;
}
signature.asc
Description: This is a digitally signed message part
Re: confusion about largefile support
On May 31, 2005, at 11:49 AM, Ben Collins-Sussman wrote: Funny, KDE is using fsfs, and I would have expected them to run into a 2GB revision file. Well, whattya know. Now Timothee Besset (ttimo) in IRC has just reported the same File size limit exceeded error that we saw on users@ earlier today. In both cases, the users were loading a dumpfile into an fsfs repository. And ttimo verified my fear. There's a 2GB file being assembled in db/txns/. So, um, maybe we should write a FAQ? One which tells folks that the only workaround here is to recompile subversion against apr 1.x? (And to upgrade to httpd 2.1 if necessary.)
Re: confusion about largefile support
On 5/31/05, Ben Collins-Sussman [EMAIL PROTECTED] wrote: On May 31, 2005, at 11:49 AM, Ben Collins-Sussman wrote: Funny, KDE is using fsfs, and I would have expected them to run into a 2GB revision file. Well, whattya know. Now Timothee Besset (ttimo) in IRC has just reported the same File size limit exceeded error that we saw on users@ earlier today. In both cases, the users were loading a dumpfile into an fsfs repository. And ttimo verified my fear. There's a 2GB file being assembled in db/txns/. So, um, maybe we should write a FAQ? One which tells folks that the only workaround here is to recompile subversion against apr 1.x? (And to upgrade to httpd 2.1 if necessary.) or use a BDB repos. bye, Erik.
Re: confusion about largefile support
Erik Huelsmann [EMAIL PROTECTED] writes: On 5/31/05, Ben Collins-Sussman [EMAIL PROTECTED] wrote: On May 31, 2005, at 11:49 AM, Ben Collins-Sussman wrote: Funny, KDE is using fsfs, and I would have expected them to run into a 2GB revision file. Well, whattya know. Now Timothee Besset (ttimo) in IRC has just reported the same File size limit exceeded error that we saw on users@ earlier today. In both cases, the users were loading a dumpfile into an fsfs repository. And ttimo verified my fear. There's a 2GB file being assembled in db/txns/. So, um, maybe we should write a FAQ? One which tells folks that the only workaround here is to recompile subversion against apr 1.x? (And to upgrade to httpd 2.1 if necessary.) or use a BDB repos. In TTimo's case, I seem to recall that the use of a BDB repos was a cause of entirely different source of pain, and therefore, not as viable an option.
