You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Aaron Bannert <aa...@ebuilt.com> on 2001/08/01 00:54:59 UTC
Re: lock benchmarks on Solaris 8/sparc uniprocessor
On Tue, Jul 31, 2001 at 02:32:48PM -0700, Aaron Bannert wrote:
> Would it be prudent for APR to provide a shared-memory implementation of
> posix mutexes? It seems to me that we don't have to rely on PROCESS_SHARED
> being available on a particular platform if we handle our own shared
> memory allocation. Are there any known caveats to this type of an
> implementation?
Er, I'm smoking crack here or something. Of course we're already doing
it this way, I just didn't notice before. *smack*
Are there any differences between that and using a SysV shmem
implementation? I'm a relative newbie when it comes to how portable
subsystems like this are.
-aaron
Re: lock benchmarks on Solaris 8/sparc uniprocessor
Posted by Ian Holsman <ia...@cnet.com>.
Aaron Bannert wrote:
>On Tue, Jul 31, 2001 at 02:32:48PM -0700, Aaron Bannert wrote:
>
>>Would it be prudent for APR to provide a shared-memory implementation of
>>posix mutexes? It seems to me that we don't have to rely on PROCESS_SHARED
>>being available on a particular platform if we handle our own shared
>>memory allocation. Are there any known caveats to this type of an
>>implementation?
>>
>
>Er, I'm smoking crack here or something. Of course we're already doing
>it this way, I just didn't notice before. *smack*
>
>Are there any differences between that and using a SysV shmem
>implementation? I'm a relative newbie when it comes to how portable
>subsystems like this are.
>
>-aaron
>
If you could implement a solaris-specific set of apr_shmem_* functions
the shared-process locking
would make use of them. (ie .. replace 'mm' )
..Ian
Re: lock benchmarks on Solaris 8/sparc uniprocessor
Posted by Ian Holsman <ia...@cnet.com>.
Aaron Bannert wrote:
>On Tue, Jul 31, 2001 at 02:32:48PM -0700, Aaron Bannert wrote:
>
>>Would it be prudent for APR to provide a shared-memory implementation of
>>posix mutexes? It seems to me that we don't have to rely on PROCESS_SHARED
>>being available on a particular platform if we handle our own shared
>>memory allocation. Are there any known caveats to this type of an
>>implementation?
>>
>
>Er, I'm smoking crack here or something. Of course we're already doing
>it this way, I just didn't notice before. *smack*
>
>Are there any differences between that and using a SysV shmem
>implementation? I'm a relative newbie when it comes to how portable
>subsystems like this are.
>
>-aaron
>
If you could implement a solaris-specific set of apr_shmem_* functions
the shared-process locking
would make use of them. (ie .. replace 'mm' )
..Ian