On Tue, Jul 03, 2001 at 03:07:30PM -0400, Jeff Trawick wrote: > It is specific not just to the platform but to the mechanism. > > I wrote a simple APR app to test this out... I'll try to find time > this evening to remove some bogosity, re-test, and post the app. I > don't think the bogosity affects the outcome but I need to > double-check.
But we can't run an APR app when we are in the middle of autoconf. =) Don't we need to have this information before we compile? I'm sensing a chicken and egg problem here. Please correct me if I'm wrong. Backing up a bit to the original point of this thread. As I see it there were two things initially addressed in Aaron's patch: 1) Removing CROSS_PROCESS and making it equivalent to LOCK_ALL. On threaded APR, a CROSS_PROCESS lock may or may not implictly acquire a intraprocess lock. I believe this is broken. We shouldn't have a lock whose granularity is dependent upon the platform and lock mechanism. In all cases that we examined (in APR and httpd), the intention of the CROSS_PROCESS locks should really be LOCK_ALL. Because some platforms/mechanisms will acquire an INTRAPROCESS lock anyway with CROSS_PROCESS and others won't, the current behavior seems ill-defined and should be standardized. The LOCK_ALL behavior seems to be the correct one at the cost of a potential extra lock acquisition where we weren't expecting the INTRAPROCESS lock in the first place. My assumption would be that this requesting this behavior (interprocess but not intraprocess) would be very rare. I'd like to see a case where we would want to lock out threads from other processes and not from our own process. Furthermore, you can't satisfy this request anyway with the current CROSS_PROCESS code as whether we obtain an intraprocess lock is undefined. You can't assume that it'll happen. In certain cases where we know that the interprocess lock will do the job of the intraprocess lock, an optimization would be to forgo acquiring the extra intraprocess lock in the LOCK_ALL code. You may also forgo this intraprocess lock if APR isn't threaded. However, we brought up the pathological case of someone using a threaded APR with a non-threaded app. Is there something we can do here to optimize this case? Should we do something about this? (This seems to be what we have been discussing over the last day or so.) However, I don't see this optimization (or lack thereof) as a showstopper or causing any bugs. I do believe the current implementation of CROSS_PROCESS will cause bugs somewhere. And, while APR is fairly malleable, it'd be nice to get this right now rather than deal with cruft later. 2) Aaron and I were confused by the names used when examining the lock code. At first glance, CROSS_PROCESS and INTRAPROCESS aren't of the same format. Why isn't INTRAPROCESS - INTRA_PROCESS? Or, CROSS_PROCESS - CROSSPROCESS? Yes, this is completely semantic, but I think something needs to change (I'm a committer, so I guess I have some say in what gets changed!). I'd be happy enough to see INTERPROCESS and INTRAPROCESS. But, the POSIX naming style (PROCESS_SHARED and PROCESS_PRIVATE) might lead to less confusion from quick glances at code fragments (was that an ER or RA?). My $.02. -- justin
