On Tue, May 31, 2016 at 01:06:23PM +0200, Jan Kiszka wrote:
> On 2016-05-30 17:20, Gilles Chanteperdrix wrote:
> > On Mon, May 30, 2016 at 04:39:42PM +0200, git repository hosting wrote:
> >> Module: xenomai-jki
> >> Branch: for-forge
> >> Commit: ec9a8c81944d4a3e3f50af314fa58ade68dd28c2
> >> URL:
> >> http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=ec9a8c81944d4a3e3f50af314fa58ade68dd28c2
> >>
> >> Author: Jan Kiszka <jan.kis...@siemens.com>
> >> Date: Mon May 30 14:58:07 2016 +0200
> >>
> >> lib/cobalt: Provide RT-capable usleep
> >>
> >> User may expect this (probably last) sleeping service to be available
> >> under Cobalt just like sleep, nanosleep & Co.
> >
> > CONFORMING TO
> > 4.3BSD, POSIX.1-2001. POSIX.1-2001 declares this function
> > obsolete;
> > use nanosleep(2) instead. POSIX.1-2008 removes the specification
> > of
> > usleep().
>
> Do you expect people - and specifically Linux - to follow this soon?
>
> The idea here is to reduce the level of surprise, and as long as using
> usleep in your app doesn't cause an "undefined symbol" error, this risk
> persists.
The thing is adding services do not come for free: it incurs a
maintenance cost. From my point of view, one of the imperatives of
the Xenomai project is to keep the code base small (and simple) so
that it remains possible to maintain it with the little work force
we have. From this point of view, adding a wrapper for a service
that has been deprecated for 15 years, and removed from the POSIX
specification for 8 years does not look like a smart move. And every
time we want to add a service, we should wonder if it is worth the
maintenance burden it incurs, this is the reason why I questioned
adding pthread_setschedprio too.
That being said, I am not opposed to this, and will happily let
other people decide. I just wanted to make sure that everyone
realized that usleep has been dead a long time.
If people use usleep, they will get a switch to secondary mode and
realize they should not use it, it is not as if it could cause a
crash or something. We might even document that somewhere.
--
Gilles.
https://click-hack.org
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
