All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Dirk Eibach <eibach@domain.hid>
Cc: xenomai-help <xenomai@xenomai.org>
Subject: Re: (WARNING!!! PGP with incorrect signature) Re: [Xenomai-help] Res
Date: Fri, 08 Sep 2006 14:59:10 +0200	[thread overview]
Message-ID: <4501691E.9010704@domain.hid> (raw)
In-Reply-To: <45015E28.7080405@domain.hid>

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

Dirk Eibach wrote:
> jan.kiszka@domain.hid wrote:
>> Dirk Eibach wrote:
>>> Hello,
>>>
>>> we have lots of tasks, semaphores and mutexes in our complex
>>> application. Stopping and restarting seems to leak some resources,
>>> because we get ENOMEM when a thread is created after restarting the
>>> application, first time everything goes well.
>>>
>>> Probably we do something wrong, maybe somebody can tell us what.
>>
>> What skin do you use? Native? Only the POSIX skin currently does
>> auto-cleanup, the others require explicit care.
> 
> We are using native skin, so that explains the problem we are facing.
> Thanks.
> 
>>> What do we have to do in order to clean up all resources properly,
>>> especially if our application is ended by SIGKILL?
>>
>> Install a signal handler and do cleanup of all allocated objects (tasks
>> get deleted when they terminate). Either keep track of your allocated
>> resources in some list(s) or signal the owners (tasks) that they should
>> terminate and cleanup their locally allocated resources. There are
>> dozens of ways to do this, depending on your application design.
>>
>> But if you think that you are cleaning up correctly and still face
>> leaks, try to derive a simple test that demonstrates the issue.
> 
> Hmmm, wouldn't it be clever to have a syscall that would allow us to
> free all xenomai resources at once, so we could call it on application
> startup? Otherwise SIGKILL will still be a problem.

Actually, the per-process cleanup is what we should head for also under
the other skins. It will also address SIGKILL (which cannot be caught by
a handler, of course). As most of us only have one brain to think and
two hands to hack, and those are also shared resources ;), support is
always welcome.

Jan


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

      parent reply	other threads:[~2006-09-08 12:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-08 11:44 [Xenomai-help] Resource leaking problem Dirk Eibach
2006-09-08 11:58 ` Jan Kiszka
2006-09-08 12:43   ` Gilles Chanteperdrix
     [not found]   ` <45015E28.7080405@domain.hid>
2006-09-08 12:59     ` Jan Kiszka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4501691E.9010704@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=eibach@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.