[EMAIL PROTECTED] wrote on 18.11.2005 09:57:15:
Exactly, I have just found out that and posted actually a long mail just
before getting this mail from you :o)
Yep, and before getting blocked, read() increments the counter as
well, that's
why we don't have a xnpipe_realease() called
Dmitry Adamushko wrote:
yep, it's a problem since data may be client-dependent. In such a case,
for a new client old messages are just irrelevant. And xnpipe_release()
cleans up the queus but, well, does it too earlier.
so,
1) should xnpipe_open_handler() and xnpipe_close_handler() be called
Philippe Gerum wrote:
Dmitry Adamushko wrote:
yep, it's a problem since data may be client-dependent. In such a
case, for a new client old messages are just irrelevant. And
xnpipe_release() cleans up the queus but, well, does it too earlier.
so,
1) should xnpipe_open_handler() and
Exactly, I have just found out that and posted actually a long mail just
before getting this mail from you :o)
Yep, and before getting blocked, read() increments the counter as well, that's
why we don't have a xnpipe_realease() called as a result of close().
So everything is correct.
Fine.
Hi,
I failed to find the original message from Sebastian that led to the following change:
-
2005-11-09 Philippe Gerum [EMAIL PROTECTED]
* nucleus/pipe.c (xnpipe_disconnect): Flush the output queue
upon closure. Issue spotted by Sebastian Smolorz.
Dmitry Adamushko wrote:
yep, it's a problem since data may be client-dependent. In such a case,
for a new client old messages are just irrelevant. And xnpipe_release()
cleans up the queus but, well, does it too earlier.
so,
1) should xnpipe_open_handler() and xnpipe_close_handler() be called
Philippe Gerum wrote:
Dmitry Adamushko wrote:
yep, it's a problem since data may be client-dependent. In such a
case, for a new client old messages are just irrelevant. And
xnpipe_release() cleans up the queus but, well, does it too earlier.
so,
1) should xnpipe_open_handler() and
Philippe Gerum [EMAIL PROTECTED] wrote on 18.11.2005 11:14:26:
...
it looks like we can't make the whole xnpipe_release() atomic because of
PREEMPT_RT + wake_up_interruptible_all() things, right? Or no.
You must _never_ _ever_ reschedule with the nucleus lock held; this
is a major
Dmitry Adamushko wrote:
Philippe Gerum [EMAIL PROTECTED] wrote on 18.11.2005 11:14:26:
...
it looks like we can't make the whole xnpipe_release() atomic
because of
PREEMPT_RT + wake_up_interruptible_all() things, right? Or no.
You must _never_ _ever_ reschedule with the
Hi,
I failed to find the original message from Sebastian that led to the
following change:
-
2005-11-09 Philippe Gerum [EMAIL PROTECTED]
* nucleus/pipe.c (xnpipe_disconnect): Flush the output queue
upon closure. Issue spotted by Sebastian Smolorz.
Philippe Gerum wrote:
Here is an update regarding the way things progress on the v2.1 branch:
o The build system has been deeply revamped, so that we now fully leave
the burden of building Xenomai's kernel support to Linux. To this end,
the code tree has been reorganized in two major
Sebastian Smolorz wrote:
Hello list,
as a result of a student research project of mine (kind of bachelor
thesis), here is a CAN device profile for RTDM including a driver for the
SJA1000-based eNET PHYTEC card. See RT-Add-On-Repository at the University
of Hannover:
12 matches
Mail list logo
