[Xenomai] Queue status files/FUSE issue -- part two

[Xenomai] Queue status files/FUSE issue -- part two

[Steve Freyder]

Greetings again,

There seems to be an issue with the RT queue status file formatting and 
perhaps
the way in which the [WAITERS] list is managed, and/or maybe the way the 
output
string termination is done.

I can't be sure and thought I should simply submit the test 
program/scripts and
document the results.  I am attaching them as a compressed tar file, I hope
that is acceptable form for the forum.

I noticed that the 32768 length in this area of the code:

./xenomai-3/lib/copperplate/registry.c-317-             case O_RDWR:
./xenomai-3/lib/copperplate/registry.c-318- sbuf->st_mode |= 0666;
./xenomai-3/lib/copperplate/registry.c-319- break;
./xenomai-3/lib/copperplate/registry.c-320-             }
./xenomai-3/lib/copperplate/registry.c-321- sbuf->st_nlink = 1;
./xenomai-3/lib/copperplate/registry.c:322: sbuf->st_size = 32768; /* 
XXX: this should be dynamic. */
./xenomai-3/lib/copperplate/registry.c-323- sbuf->st_atim = fsobj->mtime;
./xenomai-3/lib/copperplate/registry.c-324- sbuf->st_ctim = fsobj->ctime;
./xenomai-3/lib/copperplate/registry.c-325- sbuf->st_mtim = fsobj->mtime;

sometimes is altered, before the FUSE read request is satisfied, and
sometimes not.  I didn't try to trace it too far.

The script "qtest.sh" runs a program called "qx" (Queue eXerciser) to 
create a
queue, and post a read on the queue.  Two copies are launched in the 
background
then the first is killed.  The queue status file is displayed in the 
process.

Note what happens to the queue status output as you run "sh qtest.sh"
repeatedly.  On my system, I see something like what is shown below.

The included "killtask.sh" can be used to get rid of all of the 
lingering tasks
after the testing is over.

I use a lingering sysregd launched in sr.sh before starting
the testing, looks like this:

sysregd --daemon --root /var/run/xenomai/root/sess --linger

Thanks in advance,
Steve


------------------------------------------------------------------------
# sh qtest.sh
+ t1=15342
+ sleep 1
+ qx q foo r
15342:rt_queue_read(&q,buf,512,TM_INFINITE)...[unfinished]
+ t2=15348
+ kill 15342
+ qx q foo r
+ sleep 1
15348:rt_queue_read(&q,buf,512,TM_INFINITE)...[unfinished]
qtest.sh: line 10: 15342 Terminated              qx q foo r
+ qstat foo
cat /run/xenomai/root/sess/15348/alchemy/queues/foo
-------------------
[TYPE]  [TOTALMEM]  [USEDMEM]  [QLIMIT]  [MCOUNT]
  FIFO        8704          0         0         0
--
[WAITER]
task@1[15348]

-------------------
# sh qtest.sh
+ t1=15359
+ sleep 1
+ qx q foo r
15359:rt_queue_read(&q,buf,512,TM_INFINITE)...[unfinished]
+ t2=15364
+ kill 15359
+ sleep 1
+ qx q foo r
15364:rt_queue_read(&q,buf,512,TM_INFINITE)...[unfinished]
qtest.sh: line 10: 15359 Terminated              qx q foo r
+ qstat foo
cat /run/xenomai/root/sess/15348/alchemy/queues/foo
-------------------
[TYPE]  [TOTALMEM]  [USEDMEM]  [QLIMIT]  [MCOUNT]
  FIFO        8704          0         0         0
--
[WAITER]
task@1[15348]
task@1[15359]
task@1[15364]
  FIFO        8704          0         0         0
--
[W-------------------
# sh qtest.sh
+ t1=15377
+ sleep 1
+ qx q foo r
15377:rt_queue_read(&q,buf,512,TM_INFINITE)...[unfinished]
+ t2=15382
+ kill 15377
+ sleep 1
+ qx q foo r
15382:rt_queue_read(&q,buf,512,TM_INFINITE)...[unfinished]
qtest.sh: line 10: 15377 Terminated              qx q foo r
+ qstat foo
cat /run/xenomai/root/sess/15348/alchemy/queues/foo
-------------------
[TYPE]  [TOTALMEM]  [USEDMEM]  [QLIMIT]  [MCOUNT]
  FIFO        8704          0         0         0
--
[WAITER]
task@1[15348]
task@1[15359]
task@1[15364]
task@1[15377]
task@1[15382]
          0         0
--
[WAITER]
task@1[15348]
task@1[15359]
task@1[15364]
  FIFO        87-------------------
# sh qtest.sh
+ t1=15393
+ sleep 1
+ qx q foo r
15393:rt_queue_read(&q,buf,512,TM_INFINITE)...[unfinished]
+ t2=15398
+ kill 15393
+ sleep 1
+ qx q foo r
15398:rt_queue_read(&q,buf,512,TM_INFINITE)...[unfinished]
qtest.sh: line 10: 15393 Terminated              qx q foo r
+ qstat foo
cat /run/xenomai/root/sess/15348/alchemy/queues/foo
-------------------
[TYPE]  [TOTALMEM]  [USEDMEM]  [QLIMIT]  [MCOUNT]
  FIFO        8704          0         0         0
--
[WAITER]
task@1[15348]
task@1[15359]
task@1[15364]
task@1[15377]
task@1[15382]
task@1[15393]
task@1[15398]
TER]
task@1[15348]
task@1[15359]
task@1[15364]
task@1[15377]
task@1[15382]
          0         0
--
[WAITER]
task@1[15348]
task-------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: queue-status.tar.gz
Type: application/x-gzip
Size: 84280 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180416/26d4f6df/attachment.bin>

Re: [Xenomai] Queue status files/FUSE issue -- part two

[Philippe Gerum]

On 04/16/2018 09:25 PM, Steve Freyder wrote:
> Greetings again,
> 
> There seems to be an issue with the RT queue status file formatting and
> perhaps
> the way in which the [WAITERS] list is managed, and/or maybe the way the
> output
> string termination is done.
> 
> I can't be sure and thought I should simply submit the test
> program/scripts and
> document the results.  I am attaching them as a compressed tar file, I hope
> that is acceptable form for the forum.
> 
> I noticed that the 32768 length in this area of the code:
> 
> ./xenomai-3/lib/copperplate/registry.c-317-             case O_RDWR:
> ./xenomai-3/lib/copperplate/registry.c-318- sbuf->st_mode |= 0666;
> ./xenomai-3/lib/copperplate/registry.c-319- break;
> ./xenomai-3/lib/copperplate/registry.c-320-             }
> ./xenomai-3/lib/copperplate/registry.c-321- sbuf->st_nlink = 1;
> ./xenomai-3/lib/copperplate/registry.c:322: sbuf->st_size = 32768; /*
> XXX: this should be dynamic. */
> ./xenomai-3/lib/copperplate/registry.c-323- sbuf->st_atim = fsobj->mtime;
> ./xenomai-3/lib/copperplate/registry.c-324- sbuf->st_ctim = fsobj->ctime;
> ./xenomai-3/lib/copperplate/registry.c-325- sbuf->st_mtim = fsobj->mtime;
> 
> sometimes is altered, before the FUSE read request is satisfied, and
> sometimes not.  I didn't try to trace it too far.
> 
> The script "qtest.sh" runs a program called "qx" (Queue eXerciser) to
> create a
> queue, and post a read on the queue.  Two copies are launched in the
> background
> then the first is killed.  The queue status file is displayed in the
> process.
> 
> Note what happens to the queue status output as you run "sh qtest.sh"
> repeatedly.  On my system, I see something like what is shown below.
> 
> The included "killtask.sh" can be used to get rid of all of the
> lingering tasks
> after the testing is over.
> 
> I use a lingering sysregd launched in sr.sh before starting
> the testing, looks like this:

[snip]

Assuming this has been observed with applications running in a common
session, a process that dies unexpectedly in that session won't get its
threads properly removed from a shared wait list (e.g. the queue's one),
as the per-thread destructor won't have a chance to run.

Therefore killing the first process may be the cause of the behavior you
observed, because there is no general provision for being resilient to
such an event in a shared session, where it is assumed that either every
process which belongs to the session is present and functional, or the
whole session is deemed broken anyway.

Arguably, this may be an over-simplification, but that is the current
basic assumption of the whole pshared support.

-- 
Philippe.

Re: [Xenomai] Queue status files/FUSE issue -- part two

[Steve Freyder]

On 6/14/2018 11:45 AM, Philippe Gerum wrote:
> On 04/16/2018 09:25 PM, Steve Freyder wrote:
>> Greetings again,
>>
>> There seems to be an issue with the RT queue status file formatting and
>> perhaps
>> the way in which the [WAITERS] list is managed, and/or maybe the way the
>> output
>> string termination is done.
>>
>> I can't be sure and thought I should simply submit the test
>> program/scripts and
>> document the results.  I am attaching them as a compressed tar file, I hope
>> that is acceptable form for the forum.
>>
>> I noticed that the 32768 length in this area of the code:
>>
>> ./xenomai-3/lib/copperplate/registry.c-317-             case O_RDWR:
>> ./xenomai-3/lib/copperplate/registry.c-318- sbuf->st_mode |= 0666;
>> ./xenomai-3/lib/copperplate/registry.c-319- break;
>> ./xenomai-3/lib/copperplate/registry.c-320-             }
>> ./xenomai-3/lib/copperplate/registry.c-321- sbuf->st_nlink = 1;
>> ./xenomai-3/lib/copperplate/registry.c:322: sbuf->st_size = 32768; /*
>> XXX: this should be dynamic. */
>> ./xenomai-3/lib/copperplate/registry.c-323- sbuf->st_atim = fsobj->mtime;
>> ./xenomai-3/lib/copperplate/registry.c-324- sbuf->st_ctim = fsobj->ctime;
>> ./xenomai-3/lib/copperplate/registry.c-325- sbuf->st_mtim = fsobj->mtime;
>>
>> sometimes is altered, before the FUSE read request is satisfied, and
>> sometimes not.  I didn't try to trace it too far.
>>
>> The script "qtest.sh" runs a program called "qx" (Queue eXerciser) to
>> create a
>> queue, and post a read on the queue.  Two copies are launched in the
>> background
>> then the first is killed.  The queue status file is displayed in the
>> process.
>>
>> Note what happens to the queue status output as you run "sh qtest.sh"
>> repeatedly.  On my system, I see something like what is shown below.
>>
>> The included "killtask.sh" can be used to get rid of all of the
>> lingering tasks
>> after the testing is over.
>>
>> I use a lingering sysregd launched in sr.sh before starting
>> the testing, looks like this:
> [snip]
>
> Assuming this has been observed with applications running in a common
> session, a process that dies unexpectedly in that session won't get its
> threads properly removed from a shared wait list (e.g. the queue's one),
> as the per-thread destructor won't have a chance to run.
>
> Therefore killing the first process may be the cause of the behavior you
> observed, because there is no general provision for being resilient to
> such an event in a shared session, where it is assumed that either every
> process which belongs to the session is present and functional, or the
> whole session is deemed broken anyway.
>
> Arguably, this may be an over-simplification, but that is the current
> basic assumption of the whole pshared support.
>
I'm very disapppointed to hear that, it's the first I've ever heard that
documented.

The unfortunate problem with that is that it goes against the paradigms
that were present in the 2.6.x version of Xenomai, where resources owned
by threads inside a dying process were always cleaned up properly, or at
least that is what we always observed, and counted on.

It seems then that I have only two options, 1) abandon the use of pshared
and registry completely, or 2) create some kind of application layer
signal catcher that performs all of the thread cleanup.  #1 is potentially
alot of work, and #2 won't completely guarantee that the session can't be
compromised if something dies in a way the signal catcher can't clean up
after.  So I'm pretty much forced to go with #1.  I believe that means
that I have to change from using RT_QUEUE's for IPC to something like
IDDP sockets, or another facility that doesn't rely on pshared/registry
to make the required resources available cross-process.

Can RT_TASK, RT_QUEUE, RT_MUTEX, RT_SEM, etc objects be shared
cross-process using shared memory where task A calls rt_queue_create()
targetting an RT_QUEUE object in shared memory and task B uses that
object to perform an rt_queue_write() operation to that same queue?
If that worked I wouldn't need pshared/registry to share the objects
and the pshared cleanup issue would disappear.

If the answer to the above is "no", then there needs to be support for
the same kind of resource sharing that can be done using Unix Domain
Sockets on a standard Linux system that allows one process to send a
file descriptor that then becomes valid in the process receiving the
message.

Of course this all assumes that the storage tracking for an RT_QUEUE's
heap is immune to corruption when a process with that RT_QUEUE open dies,
regardless of where/how it dies.

Re: [Xenomai] Queue status files/FUSE issue -- part two

[Philippe Gerum]

On 06/14/2018 08:19 PM, Steve Freyder wrote:
> On 6/14/2018 11:45 AM, Philippe Gerum wrote:
>> On 04/16/2018 09:25 PM, Steve Freyder wrote:
>>> Greetings again,
>>>
>>> There seems to be an issue with the RT queue status file formatting and
>>> perhaps
>>> the way in which the [WAITERS] list is managed, and/or maybe the way the
>>> output
>>> string termination is done.
>>>
>>> I can't be sure and thought I should simply submit the test
>>> program/scripts and
>>> document the results.  I am attaching them as a compressed tar file,
>>> I hope
>>> that is acceptable form for the forum.
>>>
>>> I noticed that the 32768 length in this area of the code:
>>>
>>> ./xenomai-3/lib/copperplate/registry.c-317-             case O_RDWR:
>>> ./xenomai-3/lib/copperplate/registry.c-318- sbuf->st_mode |= 0666;
>>> ./xenomai-3/lib/copperplate/registry.c-319- break;
>>> ./xenomai-3/lib/copperplate/registry.c-320-             }
>>> ./xenomai-3/lib/copperplate/registry.c-321- sbuf->st_nlink = 1;
>>> ./xenomai-3/lib/copperplate/registry.c:322: sbuf->st_size = 32768; /*
>>> XXX: this should be dynamic. */
>>> ./xenomai-3/lib/copperplate/registry.c-323- sbuf->st_atim =
>>> fsobj->mtime;
>>> ./xenomai-3/lib/copperplate/registry.c-324- sbuf->st_ctim =
>>> fsobj->ctime;
>>> ./xenomai-3/lib/copperplate/registry.c-325- sbuf->st_mtim =
>>> fsobj->mtime;
>>>
>>> sometimes is altered, before the FUSE read request is satisfied, and
>>> sometimes not.  I didn't try to trace it too far.
>>>
>>> The script "qtest.sh" runs a program called "qx" (Queue eXerciser) to
>>> create a
>>> queue, and post a read on the queue.  Two copies are launched in the
>>> background
>>> then the first is killed.  The queue status file is displayed in the
>>> process.
>>>
>>> Note what happens to the queue status output as you run "sh qtest.sh"
>>> repeatedly.  On my system, I see something like what is shown below.
>>>
>>> The included "killtask.sh" can be used to get rid of all of the
>>> lingering tasks
>>> after the testing is over.
>>>
>>> I use a lingering sysregd launched in sr.sh before starting
>>> the testing, looks like this:
>> [snip]
>>
>> Assuming this has been observed with applications running in a common
>> session, a process that dies unexpectedly in that session won't get its
>> threads properly removed from a shared wait list (e.g. the queue's one),
>> as the per-thread destructor won't have a chance to run.
>>
>> Therefore killing the first process may be the cause of the behavior you
>> observed, because there is no general provision for being resilient to
>> such an event in a shared session, where it is assumed that either every
>> process which belongs to the session is present and functional, or the
>> whole session is deemed broken anyway.
>>
>> Arguably, this may be an over-simplification, but that is the current
>> basic assumption of the whole pshared support.
>>
> I'm very disapppointed to hear that, it's the first I've ever heard that
> documented.
> 
> The unfortunate problem with that is that it goes against the paradigms
> that were present in the 2.6.x version of Xenomai, where resources owned
> by threads inside a dying process were always cleaned up properly, or at
> least that is what we always observed, and counted on.

This is because 2.6 implemented every skin in kernel space, which became
a maintenance nightmare over the years. Only POSIX services are
implemented as syscalls in 3.x, with all other skins built on top of
this one via libcopperplate.

> 
> It seems then that I have only two options, 1) abandon the use of pshared
> and registry completely, or 2) create some kind of application layer
> signal catcher that performs all of the thread cleanup.  #1 is potentially
> alot of work, and #2 won't completely guarantee that the session can't be
> compromised if something dies in a way the signal catcher can't clean up
> after.  So I'm pretty much forced to go with #1.  I believe that means
> that I have to change from using RT_QUEUE's for IPC to something like
> IDDP sockets, or another facility that doesn't rely on pshared/registry
> to make the required resources available cross-process.
> 
> Can RT_TASK, RT_QUEUE, RT_MUTEX, RT_SEM, etc objects be shared
> cross-process using shared memory where task A calls rt_queue_create()
> targetting an RT_QUEUE object in shared memory and task B uses that
> object to perform an rt_queue_write() operation to that same queue?
> If that worked I wouldn't need pshared/registry to share the objects
> and the pshared cleanup issue would disappear.
> 

No, there is much more than just sharing the queue descriptor.

> If the answer to the above is "no", then there needs to be support for
> the same kind of resource sharing that can be done using Unix Domain
> Sockets on a standard Linux system that allows one process to send a
> file descriptor that then becomes valid in the process receiving the
> message.
> 

What would that solve in this specific case?

> Of course this all assumes that the storage tracking for an RT_QUEUE's
> heap is immune to corruption when a process with that RT_QUEUE open dies,
> regardless of where/how it dies.
> 
> 

Tasks, queues, mutexes and sema4s have direct counterparts in the
POSIXish libcobalt API, although POSIX queues and alchemy queues have
more differences. They can all be shared over common shm.

IDDP would be another way to implement a 1:1 or N:1 messaging system
based on the RTIPC services. That would entail a user->kernel->user copy
of each message which is heavier than what 3.x achieves since the sender
and receiver share the buffer memory directly in the latter case, but
that would exactly match what you had with 2.6 and the kernel-based
services anyway.

-- 
Philippe.

Re: [Xenomai] Queue status files/FUSE issue -- part two

[Steve Freyder]

On 6/14/2018 2:05 PM, Philippe Gerum wrote:
> On 06/14/2018 08:19 PM, Steve Freyder wrote:
>> On 6/14/2018 11:45 AM, Philippe Gerum wrote:
>>> On 04/16/2018 09:25 PM, Steve Freyder wrote:
>>>> Greetings again,
>>>>
>>>> There seems to be an issue with the RT queue status file formatting and
>>>> perhaps
>>>> the way in which the [WAITERS] list is managed, and/or maybe the way the
>>>> output
>>>> string termination is done.
>>>>
>>>> I can't be sure and thought I should simply submit the test
>>>> program/scripts and
>>>> document the results.  I am attaching them as a compressed tar file,
>>>> I hope
>>>> that is acceptable form for the forum.
>>>>
>>>> I noticed that the 32768 length in this area of the code:
>>>>
>>>> ./xenomai-3/lib/copperplate/registry.c-317-             case O_RDWR:
>>>> ./xenomai-3/lib/copperplate/registry.c-318- sbuf->st_mode |= 0666;
>>>> ./xenomai-3/lib/copperplate/registry.c-319- break;
>>>> ./xenomai-3/lib/copperplate/registry.c-320-             }
>>>> ./xenomai-3/lib/copperplate/registry.c-321- sbuf->st_nlink = 1;
>>>> ./xenomai-3/lib/copperplate/registry.c:322: sbuf->st_size = 32768; /*
>>>> XXX: this should be dynamic. */
>>>> ./xenomai-3/lib/copperplate/registry.c-323- sbuf->st_atim =
>>>> fsobj->mtime;
>>>> ./xenomai-3/lib/copperplate/registry.c-324- sbuf->st_ctim =
>>>> fsobj->ctime;
>>>> ./xenomai-3/lib/copperplate/registry.c-325- sbuf->st_mtim =
>>>> fsobj->mtime;
>>>>
>>>> sometimes is altered, before the FUSE read request is satisfied, and
>>>> sometimes not.  I didn't try to trace it too far.
>>>>
>>>> The script "qtest.sh" runs a program called "qx" (Queue eXerciser) to
>>>> create a
>>>> queue, and post a read on the queue.  Two copies are launched in the
>>>> background
>>>> then the first is killed.  The queue status file is displayed in the
>>>> process.
>>>>
>>>> Note what happens to the queue status output as you run "sh qtest.sh"
>>>> repeatedly.  On my system, I see something like what is shown below.
>>>>
>>>> The included "killtask.sh" can be used to get rid of all of the
>>>> lingering tasks
>>>> after the testing is over.
>>>>
>>>> I use a lingering sysregd launched in sr.sh before starting
>>>> the testing, looks like this:
>>> [snip]
>>>
>>> Assuming this has been observed with applications running in a common
>>> session, a process that dies unexpectedly in that session won't get its
>>> threads properly removed from a shared wait list (e.g. the queue's one),
>>> as the per-thread destructor won't have a chance to run.
>>>
>>> Therefore killing the first process may be the cause of the behavior you
>>> observed, because there is no general provision for being resilient to
>>> such an event in a shared session, where it is assumed that either every
>>> process which belongs to the session is present and functional, or the
>>> whole session is deemed broken anyway.
>>>
>>> Arguably, this may be an over-simplification, but that is the current
>>> basic assumption of the whole pshared support.
>>>
>> I'm very disapppointed to hear that, it's the first I've ever heard that
>> documented.
>>
>> The unfortunate problem with that is that it goes against the paradigms
>> that were present in the 2.6.x version of Xenomai, where resources owned
>> by threads inside a dying process were always cleaned up properly, or at
>> least that is what we always observed, and counted on.
> This is because 2.6 implemented every skin in kernel space, which became
> a maintenance nightmare over the years. Only POSIX services are
> implemented as syscalls in 3.x, with all other skins built on top of
> this one via libcopperplate.
>
>> It seems then that I have only two options, 1) abandon the use of pshared
>> and registry completely, or 2) create some kind of application layer
>> signal catcher that performs all of the thread cleanup.  #1 is potentially
>> alot of work, and #2 won't completely guarantee that the session can't be
>> compromised if something dies in a way the signal catcher can't clean up
>> after.  So I'm pretty much forced to go with #1.  I believe that means
>> that I have to change from using RT_QUEUE's for IPC to something like
>> IDDP sockets, or another facility that doesn't rely on pshared/registry
>> to make the required resources available cross-process.
>>
>> Can RT_TASK, RT_QUEUE, RT_MUTEX, RT_SEM, etc objects be shared
>> cross-process using shared memory where task A calls rt_queue_create()
>> targetting an RT_QUEUE object in shared memory and task B uses that
>> object to perform an rt_queue_write() operation to that same queue?
>> If that worked I wouldn't need pshared/registry to share the objects
>> and the pshared cleanup issue would disappear.
>>
> No, there is much more than just sharing the queue descriptor.
>
>> If the answer to the above is "no", then there needs to be support for
>> the same kind of resource sharing that can be done using Unix Domain
>> Sockets on a standard Linux system that allows one process to send a
>> file descriptor that then becomes valid in the process receiving the
>> message.
>>
> What would that solve in this specific case?
Now that I realize that all of the Alchemy layer that is in libcopperplate
is vulnerable to these cleanup issues, my idea of being able to share
those resources across processes is no good.  Prior to that I thought
that only the act of making them shareable via the registry would cause
the vulnerability, hence the idea of inventing an alternate sharing
mechanism not subject to the vulnerability would help.  Clearly not.
>
>> Of course this all assumes that the storage tracking for an RT_QUEUE's
>> heap is immune to corruption when a process with that RT_QUEUE open dies,
>> regardless of where/how it dies.
>>
>>
> Tasks, queues, mutexes and sema4s have direct counterparts in the
> POSIXish libcobalt API, although POSIX queues and alchemy queues have
> more differences. They can all be shared over common shm.
>
> IDDP would be another way to implement a 1:1 or N:1 messaging system
> based on the RTIPC services. That would entail a user->kernel->user copy
> of each message which is heavier than what 3.x achieves since the sender
> and receiver share the buffer memory directly in the latter case, but
> that would exactly match what you had with 2.6 and the kernel-based
> services anyway.
>
Yes, I realize now that step #1 when moving from 2.6 to 3.x should have
been a conversion of all of our Alchemy (native) code to Posix.  The IDDP
solution is attractive too, and I do use that now for some things. The
added overhead for the user->kernel->user copy is acceptable for our
applications.  I should be able to map all of my rt_queue_xxx calls to
equivalent mq_xxx calls using with a thin layer of inline functions to
normalize any minor semantic differences/error mapping issues.  The
queue semantics that I rely upon are global "queue name" namespace,
non-blocking open/create, non-blocking writes, and reads with timeout,
all of which appear to be fine with the mq_xxx suite.  Pretty much the
same with {rt_,posix_}{mutex,sem}_xxx, and I don't rely on those to have
cross-process semantics.