apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bray <Tim.B...@Sun.COM>
Subject Re: Corrected: global_mutex on Solaris 10, does it actually work?
Date Sat, 04 Oct 2008 06:28:09 GMT
On Oct 3, 2008, at 1:03 PM, William A. Rowe, Jr. wrote:

> If we compare this to apr_shm_create / apr_shm_attach, it's pretty  
> clear we
> are just missing the mechanics to solve this.  apr_proc| 
> global_mutex_attach
> is missing, and this should just be mopped up for apr 1.4.0, and  
> absolutely
> before 2.0.0.
>
> The other solutions that come to mind are all very, very crufty  
> hacks against
> specific solutions, e.g. an apr_os_proc_mutex_put sort of solution.   
> It really
> is the API that needs repair.

Assuming Bill's right and this is actually a missing API, let me add  
some urgency with a use case.

What I'm doing is implementing PUT, for the AtomPub protocol, against  
a file-backed store.  Since it's file-backed, it fits very nicely in  
with httpd's default code paths.

For PUT, I want to be able to support conditional update with ETags  
and If-Match headers; done correctly, this can guarantee against lost  
updates.  But this totally obviously needs a critical section. After  
you've done map_to_storage to find the file your r->uri maps to, you  
*really* need to grab a global_mutex against that file while you  
compute the ETag and compare it to the If-Match value, and either  
reject or accept-and-implement the PUT.

Summary: you can't implement PUT correctly inside httpd unless you can  
create and attach to arbitrary mutexes at runtime.

I've actually figured out a way to kludge around this, but it's kinda  
gross.

  -Tim

Mime
View raw message