[Ace-users] [ace-users] ACE_Process_Mutex has different lifetime on Windows and GNU/Linux
shuston at riverace.com
Fri Nov 23 18:34:44 CST 2007
> 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
> > 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.
> > For the first, the fact that ACE allows named semaphores to
> > their creating process with Windows and SysV semaphores but not
> > 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
I agree that it's best to have the same semantics across all
platforms. The issues behind this problem are also what causes the
Process_Manual_Event_Test to perpetually fail once it screws up until
someone hand-corrects the system and/or reboots it.
I don't recall all the issues for why they're different, though, and
why one is preferred over the other.
> > The second question is harder, or at least has broader
> > In almost all cases, the ACE_HAS_* and ACE_LACKS_* feature
> test macros
> > are defined based on whether the system simply *has* or *lacks*
> > particular feature.
> Yes, I agree that isn't sufficiently helpful for situations like
> > In cases where the system supports several ways to do
> essentially the
> > same thing, usually there is an implicit choice made within the
> > 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.
> > should probably provide some way for the developer to indicate
> > preference.
> Right, we need an "ACE_PREFERS_*" macro or something like that ;-)
Right, as we do with ACE_USES_WCHAR and ACE_HAS_WCHAR.
> > 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.
Yes, I think you're right.
> > 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
> > as it currently only checks for the existence of the features.
> > Because this muddles the definition of ACE_HAS_* and ACE_LACKS_*,
> > tend to think that there should be an ACE_USE_* or some such
> > test macro for the user to explicitly express their preference.
Yes, I agree. For autoconf, this translates to a
--enable-posix-semaphore, or similar?
> > Perhaps this all becomes moot, at least as Semaphores are
> > 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
> common semantics regardless of whether it uses POSIX semaphores or
> SysV semaphores. Steve, do you have any thoughts to share on
That's the Right Thing To Do, but I don't recall the issues behind the
> . Devise a more sophisticated set of autoconf capabilities that
> users to express their preferences when there's no clear "winner".
I think this is adding --enable options for the choice, with a
sensible default. For traditional configs, the user would have to know
to add a ACE_USES_... to the config.h file and we'd list the options
More information about the Ace-users