[Ace-users] [ace-users] ACE_Process_Mutex has different lifetime on Windows and GNU/Linux
shuston at riverace.com
Tue Nov 27 15:13:59 CST 2007
> I'm glad to see that my report/question generated some discussion.
Definitely - it's a topic that should be addressed!
> I look forward to seeing this feature in some future ACE release!
I do too - to give this idea the best chance of getting into code, I
recommend one of the following:
1. Partner with someone to work out the rationale of why the
differences exist and find a way to resolve them, develop the code,
integrate and test across all ACE platforms.
2. Make sure this information is recorded in a Bugzilla entry so it
doesn't get lost; when someone has time and/or sufficient motivation,
the details will be available to jump start the work.
Steve Huston, Riverace Corporation
Want to take ACE training on YOUR schedule?
> Douglas C. Schmidt wrote:
> > Hi J.T.,
> >> I think there are several questions:
> >> * What should be the semantics of ACE_Process_Semaphore when
> >> POSIX semaphores?
> >> * If a system supports both POSIX and SysV semaphores, which
> >> ACE prefer, and how is this preference specified by feature
> >> 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
> >> their creating process with Windows and SysV semaphores
> but not with
> >> POSIX semaphores sounds undesirable and avoidable. I'll let
> >> weigh in on this.
> > Ok, sounds good. Steve, please let us know your $0.02 worth on
> > matter.
> >> 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 this.
> >> 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. 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
> >> 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 feature
> >> test macro for the user to explicitly express their preference.
> >> 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
> > 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
> > 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
> > Thanks!
> > Doug
> ace-users mailing list
> ace-users at mail.cse.wustl.edu
More information about the Ace-users