[Ace-users] [ace-users] ACE_Process_Mutex has different lifetime on Windows and GNU/Linux
Douglas C. Schmidt
schmidt at dre.vanderbilt.edu
Wed Nov 21 16:03:16 CST 2007
> 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
> The answers to the above will answer, what, if any, changes need to be
> made to the autoconf machinery.
> 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
> 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
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
. 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".
More information about the Ace-users