On Tue, Sep 12, 2017 at 10:04 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > On 12/09/17 15:58, Gedare Bloom wrote: > >> On Tue, Sep 12, 2017 at 1:10 AM, Sebastian Huber >> <sebastian.hu...@embedded-brains.de> wrote: >>> >>> On 11/09/17 16:03, Sebastian Huber wrote: >>> >>>> ----- Joel Sherrill <j...@rtems.org> schrieb: >>>>> >>>>> On Fri, Sep 8, 2017 at 1:51 PM, Sebastian Huber < >>>>> sebastian.hu...@embedded-brains.de> wrote: >>>>> >>>>>> Ok, but why do you think that this is an error? We can share the >>>>>> synchronization objects among processes. >>>>>> >>>>> We don't have processes. How do you propose to share between >>>>> processes when RTEMS is fundamentally a single process system. >>>> >>>> Yes, its a single process system. So, it is very easy to support sharing >>>> between processes. Why should creating a process-shared synchronization >>>> object fail only because its impossible to create a second process? >>>> >>> I would like to remove this process-shared error also from the other >>> POSIX >>> synchronization objects: >>> >>> https://devel.rtems.org/ticket/3125 >>> https://devel.rtems.org/ticket/3126 >>> >> Do these process-shared synch objects work properly when used in a >> single process on *nix? > > > Yes, this is why I referred to the POSIX mutex documentation: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getpshared.html > > See also follow up (2.9.9 Synchronization Object Copies and Alternative > Mappings): > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_09 > > Which explicitly mentions semaphores. > Then I think they are good to support from a compliance standpoint.
> > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
