I did some testing without the extra mutex, and it looks good to go. Due to the UNIX documentation for the pthread signalling(that Henry pointed out), the behavior is the same."William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
At 04:56 PM 7/20/2005, Henry Jen wrote:>Good catch, you also need to r
At 04:56 PM 7/20/2005, Henry Jen wrote:
>Good catch, you also need to reset cond->signalled.
>I adapted your changes on the "else if" also the static INLINE internal
>function and created a new patch.
This is definitely coolness; do you two agree this is the complete
patch for locks/win32/thread
E Holyat wrote:
I don't use the broadcast functionality, but, it looks like that is
broken too. signal_all is never reset to 0 after the broadcast function
sets it to 1. Here is an untested fix
cond->num_waiting--;/*we have the lock(s)*/
if (cond->signal_all) {
if (cond->
Ed Holyat wrote:
I like that you were able to get rid of an extra mutex.
Their is some problems though.
There is no way to safely signal the condition, a free read and/or
write on signalled and signal_all introduces multiple race
conditions. In order for this operation to be safe, it would h
I don't use the broadcast functionality, but, it looks like that is broken too. signal_all is never reset to 0 after the broadcast function sets it to 1. Here is an untested fix
cond->num_waiting--;/*we have the lock(s)*/ if (cond->signal_all) { if (cond->num_waiting == 0) {+
E Holyat wrote:
Here is a patch for win32 that has been tested extensively for a few
months now. I submitted it to bugzilla
Based on a quick code review, I'm +1 for committing this patch.
Bill
I'm not sure how to fix it. There was a reason why I had to compile
the Ldap support into a separate library before linking the whole thing
together but sitting here at ApacheCon, its not coming to me right at
the moment. Any how, my concern is that even if I can fix the apr build
files to not
E Holyat wrote:
Here is a patch for win32 that has been tested extensively for a few
months now. I submitted it to bugzilla
The previous patch addressed only the unlock being called more than
once.
This attachment avoids race conditions that the previous patch
doesn't. This patch also fixes t
Here is a patch for win32 that has been tested extensively for a few months now. I submitted it to bugzilla
The previous patch addressed only the unlock being called more than once.
This attachment avoids race conditions that the previous patch doesn't. This patch also fixes the multiple call
Brad Nicholes wrote:
> -1 Netware. I am having build problems because of the complicated way
> that apr and apr-util build together on NetWare. The problems are
> solved if we release a new apr-util as well. I had to change the way
> NetWare builds the ldap portion of apr-util and without the up
On Wed, 20 Jul 2005, Paul Querna wrote:
> > -1 for Win32, the condvars deadlock is a serious bug. I knew this is not
> > news, but as the patch had been available for quite a while, is it
> > possible to get it fixed?
>
> No.
>
> I will not commit such a platform specific patch. Anyone who actual
Paul Querna wrote:
Henry Jen wrote:
-1 for Win32, the condvars deadlock is a serious bug. I knew this is not
news, but as the patch had been available for quite a while, is it
possible to get it fixed?
No.
I will not commit such a platform specific patch. Anyone who actually
compiles APR
Henry Jen wrote:
> Paul Querna wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Good Afternoon,
>>
>> APR 1.2.0 is ready for testing and voting for release.
>>
>> Download in your favorite archive format at:
>> http://people.apache.org/~pquerna/dev/apr-1.2.0/
>>
>> apr-1.2.0.tar.
Paul Querna wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Good Afternoon,
APR 1.2.0 is ready for testing and voting for release.
Download in your favorite archive format at:
http://people.apache.org/~pquerna/dev/apr-1.2.0/
apr-1.2.0.tar.bz2: FE 46 07 E9 28 77 4E 80 10 6F 71 19 26 18 8
-1 Netware. I am having build problems because of the complicated way
that apr and apr-util build together on NetWare. The problems are
solved if we release a new apr-util as well. I had to change the way
NetWare builds the ldap portion of apr-util and without the updates that
are in trunk for a
Paul Querna said:
> APR 1.2.0 is ready for testing and voting for release.
+1 on Solaris v2.8 (normal and Solaris PKG), MacOSX 10.3, and Fedora Core
3 (normal and RPM).
Regards,
Graham
--
On Tue, Jul 19, 2005 at 03:02:32PM +0200, Paul Querna wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Good Afternoon,
>
> APR 1.2.0 is ready for testing and voting for release.
I've told Paul this in person; but for the list:
Everything passes except for testsock on darwin 8.2.0 (1
On Tue, Jul 19, 2005 at 03:02:32PM +0200, Paul Querna wrote:
> Good Afternoon,
>
> APR 1.2.0 is ready for testing and voting for release.
+1 for release, testall runs in both apr and apr-util using that tarball
with the apr-util 1.1.2 release tarball on:
PASS: RHEL4/i686 RHEL3/i686 FC3/i686 RHE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 19, 2005, at 3:02 PM, Paul Querna wrote:
APR 1.2.0 is ready for testing and voting for release.
I'm facing problems with the test suite on both FreeBSD 5.2.1 and
Darwin 8.2.0.
The Darwin output:
[EMAIL PROTECTED] apr-1.2.0 $ make te
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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Good Afternoon,
APR 1.2.0 is ready for testing and voting for release.
Download in your favorite archive format at:
http://people.apache.org/~pquerna/dev/apr-1.2.0/
apr-1.2.0.tar.bz2: FE 46 07 E9 28 77 4E 80 10 6F 71 19 26 18 8A 5D
apr-1.2.0.tar.gz
21 matches
Mail list logo
