apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: cvs commit: apr/locks/win32 locks.c
Date Wed, 06 Jun 2001 11:47:56 GMT
>   (Attempt to) fix the build on Win32 from the sms-ified locks that David
>   checked in earlier.  This patch has a few things I don't quite like (eg,
>   the macros are duplicated across the Unix/Win32 apr_private.h files),
>   Greg has asked for an on-list discussion of David's original patch
>   so this is just a quick hack to try to get things working again in the

I'd have to say that the stuff I committed I wasn't overly happy with
either, but it moved things forward a little :(  The basic problem is that
up until now the sms code has been stand alone, it uses apr types but
doesn't use pools at all.  This is intentional as if we are ever to replace
the pools with sms then we can't really use pools can we?  Well, that's the
ideal, but we don't live in an ideal world do we? :)  I did post a while
back and ask for comments/suggestions on how to deal with this, but got no
replies.  Guess that's what happens when we're all so busy :(

The patch went in as we've been talking a lot about moving sms forward but
we need stuff like locks and file access to start adding some of the things
we'd like.  Now we have it we can start fleshing out our ideas and probably
add more code and modules.

It'd be possible to remove the stuff I committed and add a pool to each
apr_sms_t structure.  This would be used for allocating locks and other
things in APR.   However, if an app (so far only testmem) is only using sms
then I don't really see why we should force it to have a top level pool, so
each "top level" sms (at present the standard sms) would create a new top
level pool and it's children would have sub pools.  We're not talking about
large pools so this shouldn't be too bad.  The one advantage this has is it
removes the duplicated code and opens up all of APR in one move as opposed
to requiring changes to every part.

I'm torn about whether or not this is a "good" thing to do long term.
Either solution does however mean that short term we can progress the SMS
work.  I'll have a look at adopting this approach and if it works, I'll
remove the code I added and replace it with using pools.

The stuff I added did show just how far and deep our use of pools goes in
APR and threw up some things I hadn't thought of, so it was worthwhile as an
exercise, if nothing else :)

>   Unfortunately, DOS line endings are killing me and so I can't actually
>   this (MSVC won't grok .dsp files that were checked out with Unix line
>   apparently, and I don't have Win32 CVS tools handy...  sheesh), so I'll
>   to lean on you Win32 guys to make sure this gets us building again.  At
>   it still builds on Unix and *looks* reasonable for Win32, meaning that
>   patch can't have made us worse off than before.  ;-)

If I had a Win32 compiler I'd have tried to make sure it worked on Win32
before committing.  Thanks for this Ian.


View raw message