AW: [Xenomai-help] delete queues "offline"; /proc/stat

AW: [Xenomai-help] delete queues "offline"; /proc/stat

[Roderik_Wildenburg]

> > when a xenomai-task crashs which created some queues 
> > (rt_queue_create) 
> > and I try to restart the task the creation of the queues 
> > will fail as 
> > the queue still exists (error EEXIST == 17). Is there a 
> > possibility to 
> > see which queues exist (I did not find a hint in the /proc/xenomai
> > directory) and to get rid of these queues (or geneally 
> > spoken : to get 
> > rid of allocated resources) e.g. with a commandline tool ?

> 
> Native or posix skin? Gilles added per-process resource 
> cleanup to the posix skin in 2.2-rc3.
>

following Murphys law, I, of course, use native skin where this mechanism isn´t 
implemented yet ;-)
What does "per-process resource cleanup" mean ? 
When the process/thread is killed the queues and other resources of this 
process/thread are deleted automaticaly ?

> Otherwise: the names should be found in 
> /proc/xenomai/registry. Writing a tiny tool to pick up a name 
> and resources type, attach to it, and then release it should 
> be straightforward. But I think we will have per-process 
> cleanup also for other skins in the future.
> 

The trick with this is the attachement with the resource.
I can´t see a way to attach to a queue whos handle (RT_QUEUE)
is lost (it can´t be reconstructed out of the data from the 
registry).  Are there some other "tricks" ?


> Stalled RTDM descriptors can be released via "echo DESCR_NO > 
> /proc/xenomai/rtdm/open_fildes" (I still have to make use of Gilles'
> per-process cleanup also for the posix rtdm part...).
> 
> > An other question, I would appreciate some help for, is :
> > How could I determine the CPU-load when a xenomai thread is 
> running? 
> > Is the data provided by /proc/stat valid with xenomai ?
> 
> Nope, they aren't. We actually need to do something in this 
> direction, maybe a simple per-xeno-thread execution time 
> accounting if XENO_OPT_STATS is set.
> 

A summary of Xenomai used time in /proc/stat would be fine too:
CPU : "User time" "nice time" "system time" "xenomai time" "idle time".
But this probably is not compatible.



> Jan
> 
> 

Re: AW: [Xenomai-help] delete queues "offline"; /proc/stat

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]

Roderik_Wildenburg@domain.hid wrote:
>>> when a xenomai-task crashs which created some queues 
>>> (rt_queue_create) 
>>> and I try to restart the task the creation of the queues 
>>> will fail as 
>>> the queue still exists (error EEXIST == 17). Is there a 
>>> possibility to 
>>> see which queues exist (I did not find a hint in the /proc/xenomai
>>> directory) and to get rid of these queues (or geneally 
>>> spoken : to get 
>>> rid of allocated resources) e.g. with a commandline tool ?
> 
>> Native or posix skin? Gilles added per-process resource 
>> cleanup to the posix skin in 2.2-rc3.
>>
> 
> following Murphys law, I, of course, use native skin where this mechanism isn?t 
> implemented yet ;-)
> What does "per-process resource cleanup" mean ? 
> When the process/thread is killed the queues and other resources of this 
> process/thread are deleted automaticaly ?

Exactly.

> 
>> Otherwise: the names should be found in 
>> /proc/xenomai/registry. Writing a tiny tool to pick up a name 
>> and resources type, attach to it, and then release it should 
>> be straightforward. But I think we will have per-process 
>> cleanup also for other skins in the future.
>>
> 
> The trick with this is the attachement with the resource.
> I can?t see a way to attach to a queue whos handle (RT_QUEUE)
> is lost (it can?t be reconstructed out of the data from the 
> registry).  Are there some other "tricks" ?

If there is a name registered, rt_queue_bind() should do the trick - but
that's pure theory, I may oversee some detail ATM.

> 
> 
>> Stalled RTDM descriptors can be released via "echo DESCR_NO > 
>> /proc/xenomai/rtdm/open_fildes" (I still have to make use of Gilles'
>> per-process cleanup also for the posix rtdm part...).
>>
>>> An other question, I would appreciate some help for, is :
>>> How could I determine the CPU-load when a xenomai thread is 
>> running? 
>>> Is the data provided by /proc/stat valid with xenomai ?
>> Nope, they aren't. We actually need to do something in this 
>> direction, maybe a simple per-xeno-thread execution time 
>> accounting if XENO_OPT_STATS is set.
>>
> 
> A summary of Xenomai used time in /proc/stat would be fine too:
> CPU : "User time" "nice time" "system time" "xenomai time" "idle time".
> But this probably is not compatible.
> 

I've just hacked a patch for per-thread stats. Seems to work. I will
post it in a few minutes on xenomai-core together with some explanations
and suggestions. Stay tuned!

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: AW: [Xenomai-help] delete queues "offline"; /proc/stat

[Gilles Chanteperdrix]

Roderik_Wildenburg@domain.hid wrote:
 > > > when a xenomai-task crashs which created some queues 
 > > > (rt_queue_create) 
 > > > and I try to restart the task the creation of the queues 
 > > > will fail as 
 > > > the queue still exists (error EEXIST == 17). Is there a 
 > > > possibility to 
 > > > see which queues exist (I did not find a hint in the /proc/xenomai
 > > > directory) and to get rid of these queues (or geneally 
 > > > spoken : to get 
 > > > rid of allocated resources) e.g. with a commandline tool ?
 > 
 > > 
 > > Native or posix skin? Gilles added per-process resource 
 > > cleanup to the posix skin in 2.2-rc3.
 > >
 > 
 > following Murphys law, I, of course, use native skin where this mechanism isn´t 
 > implemented yet ;-)
 > What does "per-process resource cleanup" mean ? 
 > When the process/thread is killed the queues and other resources of this 
 > process/thread are deleted automaticaly ?

Yes, all resources specific to a process are deleted automatically, so,
any message queue descriptor or shared memory descriptor is
closed. Named objects are not deleted though, since they may be shared
between several processes, only non-pshared anonymous objects and named
objects *descriptors* are deleted. This is the only reasonable
implementation I could find.

-- 


					    Gilles Chanteperdrix.

Re: AW: [Xenomai-help] delete queues "offline"; /proc/stat

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

Gilles Chanteperdrix wrote:
> Roderik_Wildenburg@domain.hid wrote:
>  > > > when a xenomai-task crashs which created some queues 
>  > > > (rt_queue_create) 
>  > > > and I try to restart the task the creation of the queues 
>  > > > will fail as 
>  > > > the queue still exists (error EEXIST == 17). Is there a 
>  > > > possibility to 
>  > > > see which queues exist (I did not find a hint in the /proc/xenomai
>  > > > directory) and to get rid of these queues (or geneally 
>  > > > spoken : to get 
>  > > > rid of allocated resources) e.g. with a commandline tool ?
>  > 
>  > > 
>  > > Native or posix skin? Gilles added per-process resource 
>  > > cleanup to the posix skin in 2.2-rc3.
>  > >
>  > 
>  > following Murphys law, I, of course, use native skin where this mechanism isn?t 
>  > implemented yet ;-)
>  > What does "per-process resource cleanup" mean ? 
>  > When the process/thread is killed the queues and other resources of this 
>  > process/thread are deleted automaticaly ?
> 
> Yes, all resources specific to a process are deleted automatically, so,
> any message queue descriptor or shared memory descriptor is
> closed. Named objects are not deleted though, since they may be shared
> between several processes, only non-pshared anonymous objects and named
> objects *descriptors* are deleted. This is the only reasonable
> implementation I could find.

What about a usage counter maintained on creation/binding vs.
closing/destruction? I would prefer to get them cleaned up automatically
as well somehow, or we really need tool support for IPC cleanup, and
that is ugly in my eyes.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: AW: [Xenomai-help] delete queues "offline"; /proc/stat

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > > Yes, all resources specific to a process are deleted automatically, so,
 > > any message queue descriptor or shared memory descriptor is
 > > closed. Named objects are not deleted though, since they may be shared
 > > between several processes, only non-pshared anonymous objects and named
 > > objects *descriptors* are deleted. This is the only reasonable
 > > implementation I could find.
 > 
 > What about a usage counter maintained on creation/binding vs.
 > closing/destruction? I would prefer to get them cleaned up automatically
 > as well somehow, or we really need tool support for IPC cleanup, and
 > that is ugly in my eyes.

I am not sure one would expect a named object to be unlinked when one only
calls its "close" service, without calling its "unlink" service. If, on
the other hand, one calls the "unlink" service, then the object will be
automatically destroyed when the last descriptor is closed, as mandated
by the specification.

Moreover, the existence of such objects is not a leak that will grow
over time, if one do not use the O_EXCL flag when opening objects,
existing objects will simply be reused. If one use the O_EXCL flag,
opening will fail.

This behaviour is the same as Linux behaviour.

-- 


					    Gilles Chanteperdrix.

Re: AW: [Xenomai-help] delete queues "offline"; /proc/stat

[Philippe Gerum]

On Thu, 2006-07-06 at 13:59 +0200, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > > Yes, all resources specific to a process are deleted automatically, so,
>  > > any message queue descriptor or shared memory descriptor is
>  > > closed. Named objects are not deleted though, since they may be shared
>  > > between several processes, only non-pshared anonymous objects and named
>  > > objects *descriptors* are deleted. This is the only reasonable
>  > > implementation I could find.
>  > 
>  > What about a usage counter maintained on creation/binding vs.
>  > closing/destruction? I would prefer to get them cleaned up automatically
>  > as well somehow, or we really need tool support for IPC cleanup, and
>  > that is ugly in my eyes.
> 
> I am not sure one would expect a named object to be unlinked when one only
> calls its "close" service, without calling its "unlink" service. If, on
> the other hand, one calls the "unlink" service, then the object will be
> automatically destroyed when the last descriptor is closed, as mandated
> by the specification.

I agree with this interpretation. Think of some application "loader"
process that just creates the basic infrastructure, like shared mem
segs, then exits, leaving the actual use of such resources to some other
processes. I did see this a few times in customer designs.

> 
> Moreover, the existence of such objects is not a leak that will grow
> over time, if one do not use the O_EXCL flag when opening objects,
> existing objects will simply be reused. If one use the O_EXCL flag,
> opening will fail.
> 
> This behaviour is the same as Linux behaviour.
> 
-- 
Philippe.

Re: AW: [Xenomai-help] delete queues "offline"; /proc/stat

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > > Yes, all resources specific to a process are deleted automatically, so,
>  > > any message queue descriptor or shared memory descriptor is
>  > > closed. Named objects are not deleted though, since they may be shared
>  > > between several processes, only non-pshared anonymous objects and named
>  > > objects *descriptors* are deleted. This is the only reasonable
>  > > implementation I could find.
>  > 
>  > What about a usage counter maintained on creation/binding vs.
>  > closing/destruction? I would prefer to get them cleaned up automatically
>  > as well somehow, or we really need tool support for IPC cleanup, and
>  > that is ugly in my eyes.
> 
> I am not sure one would expect a named object to be unlinked when one only
> calls its "close" service, without calling its "unlink" service. If, on
> the other hand, one calls the "unlink" service, then the object will be
> automatically destroyed when the last descriptor is closed, as mandated
> by the specification.

But if the creator of an object dies + there are no further open
instances, I see no practical reason to keep this alive. I'm talking
about the check on process exit here, not on explicit close().

> 
> Moreover, the existence of such objects is not a leak that will grow
> over time, if one do not use the O_EXCL flag when opening objects,
> existing objects will simply be reused. If one use the O_EXCL flag,
> opening will fail.
> 
> This behaviour is the same as Linux behaviour.
> 

Well, I have sys-v ipc in mind where I used to fiddle a lot with ipcrm
to get certain applications running again after unexpected termination.
The reason was that the developers used the existence of certain ipc
names to check if a central component was already running.

Maybe it's really dependent on the actual ipc mechanism, and having the
one characteristic for posix and some other later for native might be
the way to go.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]