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

[Steve Huston]

Hi guys,

> 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.

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
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.

Right.

> > 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 ;-)

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 
> 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.

Yes, I agree. For autoconf, this translates to a
--enable-posix-semaphore, or similar?

> > 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?

That's the Right Thing To Do, but I don't recall the issues behind the
differences offhand.

> . Devise a more sophisticated set of autoconf capabilities that
allow
>   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
in ace/README

-Steve