[Ace-users] [ace-users] ACE_Process_Mutex has different lifetime on Windows and GNU/Linux

[Douglas C. Schmidt]

Hi J.T.,

> I think there are several questions:
> 
> * What should be the semantics of ACE_Process_Semaphore when using
>   POSIX semaphores?
> 
> * If a system supports both POSIX and SysV semaphores, which should
>   ACE prefer, and how is this preference specified by feature test
>   macros.
> 
> The answers to the above will answer, what, if any, changes need to be
> made to the autoconf machinery.

Right!

> For the first, the fact that ACE allows named semaphores to outlive
> their creating process with Windows and SysV semaphores but not with
> POSIX semaphores sounds undesirable and avoidable.  I'll let Steve
> weigh in on this.

Ok, sounds good.  Steve, please let us know your $0.02 worth on this
matter.

> The second question is harder, or at least has broader implications.
> In almost all cases, the ACE_HAS_* and ACE_LACKS_* feature test macros
> are defined based on whether the system simply *has* or *lacks* the
> particular feature.

Yes, I agree that isn't sufficiently helpful for situations like this.

> In cases where the system supports several ways to do essentially the
> same thing, usually there is an implicit choice made within the ACE
> code to use prefer one over the other(s). In many cases the choice is
> the obviously correct one, made on suitability or portability or some
> other -ibility. But there are cases where it's not so clear cut. ACE
> should probably provide some way for the developer to indicate their
> preference.

Right, we need an "ACE_PREFERS_*" macro or something like that ;-)
 
> One way to do that would be to simply not define the feature test
> macro for alternate implementation.  I believe this is what Lars'
> experienced when he changed from the autoconf generated to canned
> config.h, which didn't define ACE_HAS_POSIX_SEM.
> 
> However, this complicates and confuses the definitions of those
> feature test macros, as it overloads them to mean the system
> *has/lacks* the feature *and* for ACE to *use/avoid* the feature.
> This is where whatever choice we make impacts the autoconf machinery,
> as it currently only checks for the existence of the features.
> Because this muddles the definition of ACE_HAS_* and ACE_LACKS_*, I
> tend to think that there should be an ACE_USE_* or some such feature
> test macro for the user to explicitly express their preference.
> 
> Perhaps this all becomes moot, at least as Semaphores are concerned,
> if it turns out that they are changed not to delete the file and then
> POSIX semaphores are the obviously correct choice. If not, we'll need
> to agree on a strategy/roadmap and migrate towards that over time.

I agree that we need a multi-faceted approach here.  Perhaps the way to
proceed is:

. Figure out what to do for the ACE_Process_Mutex stuff so that it has
  common semantics regardless of whether it uses POSIX semaphores or
  SysV semaphores.  Steve, do you have any thoughts to share on this?
  
. Devise a more sophisticated set of autoconf capabilities that allow
  users to express their preferences when there's no clear "winner".
  
Thanks!

        Doug