From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Xenomai core <Xenomai-core@domain.hid>
Subject: Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : RTDM+POSIX: Avoid leaking binding objects on errors
Date: Mon, 01 Mar 2010 12:22:09 +0100 [thread overview]
Message-ID: <4B8BA361.1040807@domain.hid> (raw)
In-Reply-To: <4B8B98F5.10602@domain.hid>
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Jan Kiszka wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Gilles Chanteperdrix wrote:
>>>>>>> GIT version control wrote:
>>>>>>>> diff --git a/ksrc/skins/posix/mq.c b/ksrc/skins/posix/mq.c
>>>>>>>> index 11f47c0..a896031 100644
>>>>>>>> --- a/ksrc/skins/posix/mq.c
>>>>>>>> +++ b/ksrc/skins/posix/mq.c
>>>>>>>> @@ -1283,6 +1283,7 @@ int pse51_mq_select_bind(mqd_t fd, struct xnselector *selector,
>>>>>>>> return 0;
>>>>>>>>
>>>>>>>> unlock_and_error:
>>>>>>>> + xnfree(binding):
>>>>>>>> xnlock_put_irqrestore(&nklock, s);
>>>>>>>> return err;
>>>>>>>> }
>>>>>>> Ok. Will pull. But I really need to fix that.
>>>>>>>
>>>>>> Ack - now that I see it myself.
>>>>>>
>>>>> I fixed this in my branch and added another patch to transform EIDRM
>>>>> into EBADF when selecting a (half-)deleted RTDM device. Please merge.
>>>>>
>>>> Wait! When the sync object behind some file descriptor is deleted but
>>>> the descriptor itself is still existing, we rather have to return that
>>>> fd signaled from select() instead of letting the call fail. I beed to
>>>> look into this again.
>>> It looks to me like a transitory state, we can wait for the sync object
>>> to be deleted to have the fd destructor signaled. It should not be long.
>> That's not an issue of waiting for this. See e.g. TCP: peer closes
>> connection -> internal sync objects will be destroyed (to make
>> read/write fail). But the fd will remain valid until the local side
>> closes it as well.
>
> It looks to me like this is going to complicate things a lot, and will
> be a source of regressions. Why can we not have sync objects be
> destroyed when the fd is really destroyed and use a status bit of some
> kind to signal read/write that the fd was closed by peer?
It is way easier and more consistent to unblock reader and writers via
destroying the sync object than to signal it and add tests for specific
states to detect that. Keep in mind that this pattern is in use even
without select support. Diverging from it just to add select awareness
to some driver would be a step back.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2010-03-01 11:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1Nl4tX-0001N9-Hb@domain.hid>
2010-02-26 19:18 ` [Xenomai-core] [Xenomai-git] Jan Kiszka : RTDM+POSIX: Avoid leaking binding objects on errors Gilles Chanteperdrix
2010-02-26 19:25 ` Jan Kiszka
2010-02-27 11:37 ` Jan Kiszka
2010-03-01 8:05 ` Jan Kiszka
2010-03-01 9:11 ` Gilles Chanteperdrix
2010-03-01 10:29 ` Jan Kiszka
2010-03-01 10:37 ` Gilles Chanteperdrix
2010-03-01 11:22 ` Jan Kiszka [this message]
2010-03-01 12:46 ` Jan Kiszka
2010-03-01 12:49 ` Jan Kiszka
2010-03-01 13:34 ` Gilles Chanteperdrix
2010-03-01 13:50 ` Jan Kiszka
2010-03-01 14:15 ` Gilles Chanteperdrix
2010-03-01 14:22 ` Jan Kiszka
2010-03-01 14:26 ` Gilles Chanteperdrix
2010-03-01 14:29 ` Gilles Chanteperdrix
2010-03-01 14:53 ` Jan Kiszka
2010-03-01 15:27 ` Gilles Chanteperdrix
2010-03-01 15:34 ` Gilles Chanteperdrix
2010-03-01 16:25 ` Jan Kiszka
2010-03-01 16:19 ` Gilles Chanteperdrix
2010-03-01 13:36 ` Gilles Chanteperdrix
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=4B8BA361.1040807@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=Xenomai-core@domain.hid \
--cc=gilles.chanteperdrix@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.