Notes |
(0002860)
shware_systems (reporter)
2015-10-08 12:56
|
That is something for LINUX to address, as POSIX does not appear to impose that restriction. It makes allowance for it by EAGAIN in pthread_mutex_init(), as to how many can be owned, but does not impose a per process limit on how many can be referenced by sharing. The implicit limit on that is available memory, that I can see. |
|
(0002861)
Florian Weimer (reporter)
2015-10-08 13:22
|
Unfortunately, pthread_mutex_init is not the only way to add mutexes to a process which can be locked later. If we do not check the limit at lock time, we would have to check at mmap time if the mapping contains any robust mutexes, and proactively fail mmap if the implementation limit is exceeded. |
|
(0002862)
shware_systems (reporter)
2015-10-08 14:01
|
I would say it is more on those other ways to respect any implementation-defined limits of this nature, if they are populating the per-process structures with data directly. After a mmap() the process still has to init references to locks in that address space; wouldn't trying to reuse another process's handle directly count against that previous process, not the one doing the new map? |
|
(0002867)
jilles (reporter)
2015-10-08 22:08
|
This seems to be a duplicate of #354. |
|
(0002868)
shware_systems (reporter)
2015-10-09 11:15
|
Mostly... The resolution of #354 is per-system, not per-process, though, and by the wording it's a may fail error, depending on implementation model. I don't have the 2008 pdf handy to compare line numbers. The Rationale also could have something that explains that it may not occur on all platforms, so this could be a child issue. |
|