> (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), but > Greg has asked for an on-list discussion of David's original patch anyway, > so this is just a quick hack to try to get things working again in the meanwhile.
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 test > this (MSVC won't grok .dsp files that were checked out with Unix line endings, > apparently, and I don't have Win32 CVS tools handy... sheesh), so I'll have > to lean on you Win32 guys to make sure this gets us building again. At least > it still builds on Unix and *looks* reasonable for Win32, meaning that this > 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. david
