apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amit Athavale <amit_athav...@persistent.co.in>
Subject Re: apr_shm_attach() and APR_EEXIST
Date Mon, 31 May 2004 13:26:02 GMT
  Attached are revised patches (diff against HEAD and changes suggested 
by Joe)

Regarding other platforms(beos, win32, os2), I have a simple question ;)
Do we need to implement apr_shm_remove ? (or just return APR_ENOTIMPL)

Frankly speaking I have very little knowledge about beos and os2.
Just looking at APIs, I don't think there should be case of orphan 
segments and
if it is there, I didn't find a way to remove that segment just on the 
basis of
filename like we do in shm_xxx API.

Win32 has same case AFAIK. You can call "OpenFileMapping", but there is
no way to *destroy* file mapping which was created by some other process
which has died.

Suggestions ?


Joe Orton wrote:

>On Fri, May 28, 2004 at 05:08:17PM +0530, Amit Athavale wrote:
>>Here is initial patch:
>>- only for unix, if this OK I will write for other platforms
>>- Tested on linux RH 8.0 and solaris 9
>>- New test case added in testshm.c
>>Please review it so I can provide patch for other platforms ASAP.
>Looks good, thanks a lot Amit... patch against APR HEAD would be
>preferred though.  There's no need for apr_shm_remove() to have an
>APR_ENOTIMPL case: the caller knows not to call this function for an
>anonymous segment.
>You can collapse:
>  rv = apr_file_remove();
>  if (rv) return rv;
>  return APR_SUCCESS;
>into just "return apr_file_remove();"

View raw message