apr_dso_load

["Marc M. Adkins" <So...@Doorways.org>]

I was working with APR on Windows a half-year ago and used apr_dso_load() a 
fair amount.  I could have sworn that the load functionality followed the 
PATH environment variable setting when loading modules.  I could easily be 
wrong about that, and I've not got a loaded Windows system around right now.

Since then I've moved completely over to Linux and I'm attempting to pick up 
that old code and move on with it.  I'm trying to figure out how to get my 
modules to load and the unix variant of apr_dso_load() is using 
NSLinkModule() (shades of Great NextStep's Ghost?) which apparently (?) 
doesn't follow the *nix convention (?) of following LD_LIBRARY_PATH.

So...the apr_dso_load() documentation isn't really clear on this.  Is there / 
should there be a path for apr_dso_load() to follow?  Do I misremember the 
Windows behavior?

mma

PS  Is there a mail archive for this list?

Re: recursive apr_thread_rwlock_wrlock?

["Marc M. Adkins" <So...@Doorways.org>]

On Tuesday 30 March 2004 03:16 am, Joe Orton wrote:
> On Mon, Mar 29, 2004 at 05:22:20PM -0500, Marc M. Adkins wrote:
> > On Monday 29 March 2004 01:16 am, Joe Orton wrote:
> > > On Sun, Mar 28, 2004 at 04:57:53PM -0500, Marc M. Adkins wrote:
> > > > Is it possible that apr_thread_rwlock_wrlock will allow recursive
> > > > behavior on Windows but not on Linux?  By this I mean that a specific
> > > > thread will request a write lock and then request the same write lock
> > > > again, intending to release it twice on the way out:
> > >
> > > Yes, that gives undefined behaviour in a POSIX implementation,
> > > apr_thread_rwlock.h on HEAD says:
> >
> > I am apparently not using anything close to the HEAD.
>
> No, not your fault, the comment isn't in 0.9.x and really should be.

> There are probably lots of things like this which are not documented at
> all in APR; if you want to get a better understanding of the assumptions
> you can make in threaded code on POSIXy systems you'd be well advised to
> go and read the relevant bits of the Single Unix spec: e.g.
> http://www.opengroup.org/onlinepubs/007904975/

Hey, that's a useful reference.

It's interesting that pthread_rwlock_wrlock() returns EDEADLK in the specific 
recursive call circumstance I describe.  Which would imply that a second lock 
from the same thread would wait on itself (as I observe it to do).  And yet 
the behavior is still not really defined, as you say.

Let me stray for a moment to my only contribution to this effort, dating back 
to June of last year.  I had discovered that the Win32 implementation of 
apr_thread_rwlock() starved writers.  I had a little test program that 
demonstrated that writers never wrote when there were too many overlapping 
readers.  On Linux it seemed to work OK, but on Windows it just wasn't good.

So after some correspondance on this very mailing list I took Brian Havard's 
OS/2 implementation of a non-starving rwlock and converted it very slightly 
for Win32 and it eventually made it into the code.  So now the APR rwlock is 
actually constructed of a mutex, an event, and a long integer on Win32 and it 
has a more predictable behavior, as well as being arguably more 'corrrect'.

Back to the current situation:  is it better to just say that the behavior is 
unpredictable (as in the recursive lock case) or to use available resources 
to construct something that has predictable behavior (as in the starvation 
case)?

I'm thinking that the starvation issue was 'wrong' in the sense that one 
couldn't build with it properly and therefore it needed to be fixed, whereas 
the recursive calls case isn't so much wrong as 'non-optimal,' it's perfectly 
usable as is, and I should have known better than to make such a ridiculous 
assumption in the first place.  Still, the solution in either case is 
essentially building a wrapper that combines multiple unpredictable beasties 
in such a way that the result becomes predicable.

Is there an articulated dividing line of some sort in these things?

mma

Re: recursive apr_thread_rwlock_wrlock?

[Joe Orton <jo...@manyfish.co.uk>]

On Mon, Mar 29, 2004 at 05:22:20PM -0500, Marc M. Adkins wrote:
> On Monday 29 March 2004 01:16 am, Joe Orton wrote:
> > On Sun, Mar 28, 2004 at 04:57:53PM -0500, Marc M. Adkins wrote:
> > > Is it possible that apr_thread_rwlock_wrlock will allow recursive
> > > behavior on Windows but not on Linux?  By this I mean that a specific
> > > thread will request a write lock and then request the same write lock
> > > again, intending to release it twice on the way out:
> >
> > Yes, that gives undefined behaviour in a POSIX implementation,
> > apr_thread_rwlock.h on HEAD says:
> 
> I am apparently not using anything close to the HEAD.

No, not your fault, the comment isn't in 0.9.x and really should be. 

There are probably lots of things like this which are not documented at
all in APR; if you want to get a better understanding of the assumptions
you can make in threaded code on POSIXy systems you'd be well advised to
go and read the relevant bits of the Single Unix spec: e.g.
http://www.opengroup.org/onlinepubs/007904975/

Regards,

joe

Re: recursive apr_thread_rwlock_wrlock?

["Marc M. Adkins" <So...@Doorways.org>]

On Monday 29 March 2004 01:16 am, Joe Orton wrote:
> On Sun, Mar 28, 2004 at 04:57:53PM -0500, Marc M. Adkins wrote:
> > Is it possible that apr_thread_rwlock_wrlock will allow recursive
> > behavior on Windows but not on Linux?  By this I mean that a specific
> > thread will request a write lock and then request the same write lock
> > again, intending to release it twice on the way out:
>
> Yes, that gives undefined behaviour in a POSIX implementation,
> apr_thread_rwlock.h on HEAD says:

I am apparently not using anything close to the HEAD.  I downloaded the 
'latest' Apache since I needed both that and APR...figured that would be good 
enough...I could just link in the APR that came with Apache.  Perhaps an 
oversight.  Easy to correct (and...done).  So at least I can read the _right_ 
comments, eh?

Before pinging the mailing list I had also checked:

	http://apr.apache.org/docs/apr/group__apr__thread__rwlock.html

'Course that page was apparently generated 2003/06/25, so no HEAD there 
either.

thx,
mma

Re: recursive apr_thread_rwlock_wrlock?

[Joe Orton <jo...@manyfish.co.uk>]

On Sun, Mar 28, 2004 at 04:57:53PM -0500, Marc M. Adkins wrote:
> Is it possible that apr_thread_rwlock_wrlock will allow recursive behavior on 
> Windows but not on Linux?  By this I mean that a specific thread will request 
> a write lock and then request the same write lock again, intending to release 
> it twice on the way out:

Yes, that gives undefined behaviour in a POSIX implementation,
apr_thread_rwlock.h on HEAD says:

/**
 * Note: The following operations have undefined results: unlocking a
 * read-write lock which is not locked in the calling thread; write
 * locking a read-write lock which is already locked by the calling
 * thread; destroying a read-write lock more than once; clearing or
 * destroying the pool from which a <b>locked</b> read-write lock is
 * allocated.
 */

Regards,

joe

recursive apr_thread_rwlock_wrlock?

["Marc M. Adkins" <So...@Doorways.org>]

Is it possible that apr_thread_rwlock_wrlock will allow recursive behavior on 
Windows but not on Linux?  By this I mean that a specific thread will request 
a write lock and then request the same write lock again, intending to release 
it twice on the way out:

	void XXX () {
	  wrlock(lck);
	  YYY();
	  unlock(lck);
	}

	void YYY () {
	  wrlock(lck);
	  unlock(lck);
	}

Seems like I have code I developed under Windows that assumes that this works, 
but it's not working under Linux.  Is there an official behavior?

mma

Re: apr_dso_load

[Cliff Woolley <jw...@virginia.edu>]

On Wed, 24 Mar 2004, Marc M. Adkins wrote:

> PS  Is there a mail archive for this list?

Well I can at least answer this half.  ;)  Yes, there are several.
Here are a few web-based ones:

http://marc.theaimsgroup.com/?l=apr-dev&r=1&w=2
http://nagoya.apache.org/eyebrowse/SummarizeList?listId=183

--Cliff