> Yes, even RTEMS5 without the new libbsd-network-stack has not defined
> _XOPEN_SOURCE and asks for the old implementation. I can set _XOPEN_SOURCE by
> hand and it works so far with it. But what I noticed in this context and I
> think that the mutexes may be used incorrectly in some modules and therefore
> it comes to problems such as: "mutex not owned by the task".
>
> I saw the whole thing in the context of MotorRecords (OMS):
>
> https://github.com/epics-modules/motor/issues/172
>
> I see a general problem that probably in some places mutexes are created in
> the iocInit task and then used afterwards in other tasks although the iocInit
> task has been terminated.
>
> As I understand it, mutexes should generally be created in the tasks in which
> they are also used? Or with shared memory the creating task must remain
> however existing?
If you build RTEMS with the POSIX_FLAGS like in Linux (-D_GNU_SOURCE -D_DEFAULT_SOURCE) then with the help of includes/sys/features.h _XOPENS_SOURCE is defined to 700.
--
https://code.launchpad.net/~dirk.zimoch/epics-base/+git/epics-base/+merge/394327
Your team EPICS Core Developers is subscribed to branch epics-base:7.0.
- Navigate by Date:
- Next:
[Bug 1910148] [NEW] Broadcast address detection is unreliable on Linux Michael Ritzert via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
- Navigate by Thread:
- Next:
Re: [Merge] ~dirk.zimoch/epics-base:epicsMutexPriorityInheritance into epics-base:7.0 Dirk Zimoch via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|