[Xenomai-help] uClinux write to pipe returning -ENOMEM

[Xenomai-help] uClinux write to pipe returning -ENOMEM

[Filip Van Rillaer]

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

Hello,
 
I am opening the uClinux side of a Xenomai pipe like (so in blocking
mode):
FdPipe = open(PipeName, O_RDWR);
After some writes to FdPipe I get the returnvalue -ENOMEM.
I can understand that the internal buffer gets full as my application is
writing data faster than the Xenomai side is consuming, but I don't
expect to see a returnvalue -ENOMEM : the calling writing-thread should
block, isn't it?  Please comment.
 
(When adding the O_SYNC flag things get even worse)
 
Why is the code for xnpipe_write saying:
if (!mh) 
  /* Cannot sleep. */   <--- ???????????????????
  return -ENOMEM;
 
I am using svn version 4105.
 
Best regards,
Filip

[-- Attachment #2: Type: text/html, Size: 2523 bytes --]

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Philippe Gerum]

Filip Van Rillaer wrote:
> Hello,
>  
> I am opening the uClinux side of a Xenomai pipe like (so in blocking mode):
> FdPipe = open(PipeName, O_RDWR);
> After some writes to FdPipe I get the returnvalue -ENOMEM.
> I can understand that the internal buffer gets full as my application is
> writing data faster than the Xenomai side is consuming, but I don't
> expect to see a returnvalue -ENOMEM : the calling writing-thread should
> block, isn't it?  Please comment.
>

RT is assumed to consume asap and will preempt the non-RT write() caller
immediately upon data receipt, unless the RT code uses some kind of timed
polling, which is considered useless and inefficient, since you can ask a RT
thread to wait for incoming data in a blocking way.

> (When adding the O_SYNC flag things get even worse)
>  

That is the point that would actually need fixing: what happens with O_SYNC,
what is worsening exactly?

> Why is the code for xnpipe_write saying:
> if (!mh)
>   /* Cannot sleep. */   <--- ???????????????????
>   return -ENOMEM;
>  
> I am using svn version 4105.
>  
> Best regards,
> Filip
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Philippe Gerum]

Filip Van Rillaer wrote:
> Hello,
> 
> My current test-setup is as follows:
> 1) user-program reads test-samples from a file in non-RT and does a blocking write to the Xenomai-pipe
> 2) a RT-program that implements a V34 modem is listening to the Xenomai-pipe and will send the data over a telephone line.
> ---> so it is the intention that at startup the Xenomai-pipe buffer gets filled up and from than in stationary state the data should stream at the speed of the V34 modem connection.
> 
> The RT-side is using rt_pipe_monitor to be warned when new data from the non-RT write arrives (so no polling).  The RT-side will 'remember' that data from the non-RT side are available and (sometimes a lot) later when enough data have been sent over the telephone line, read new data from the Xenomai pipe.
> 
> Any idea how I can get around this problem?
>

Well, yes. /Me fixing my mess.

> Concerning O_SYNC I get the fatal error message:
>  Xenomai: fatal: inserting element twice, holder=00b19cfc, qslot=00b1ab84 at kernel/xenomai/nucleus/pipe.c:96

Oh dear...

>   CPU  PID    PRI      TIMEOUT  STAT      NAME
>  >  0  0       -1      0        00400080  ROOT
>     0  112     99      999616310 00300186  RTTask
> I think that this happens around the same time that I get the -ENOMEM when I am not using the O_SYNC flag.
> 

Ok, once again, I need to reproduce this first. More later,

> Best regards,
> Filip
>  
> 
> -----Original Message-----
> From: Philippe Gerum [mailto:rpm@xenomai.org] 
> Sent: 19 August 2008 18:31
> To: Filip Van Rillaer
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM
> 
> Filip Van Rillaer wrote:
>> Hello,
>>  
>> I am opening the uClinux side of a Xenomai pipe like (so in blocking mode):
>> FdPipe = open(PipeName, O_RDWR);
>> After some writes to FdPipe I get the returnvalue -ENOMEM.
>> I can understand that the internal buffer gets full as my application 
>> is writing data faster than the Xenomai side is consuming, but I don't 
>> expect to see a returnvalue -ENOMEM : the calling writing-thread 
>> should block, isn't it?  Please comment.
>>
> 
> RT is assumed to consume asap and will preempt the non-RT write() caller immediately upon data receipt, unless the RT code uses some kind of timed polling, which is considered useless and inefficient, since you can ask a RT thread to wait for incoming data in a blocking way.
> 
>> (When adding the O_SYNC flag things get even worse)
>>  
> 
> That is the point that would actually need fixing: what happens with O_SYNC, what is worsening exactly?
> 
>> Why is the code for xnpipe_write saying:
>> if (!mh)
>>   /* Cannot sleep. */   <--- ???????????????????
>>   return -ENOMEM;
>>  
>> I am using svn version 4105.
>>  
>> Best regards,
>> Filip
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
> 
> 
> --
> Philippe.
> 


-- 
Philippe.

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Philippe Gerum]

Filip Van Rillaer wrote:
> Hello,
> 
> My current test-setup is as follows:
> 1) user-program reads test-samples from a file in non-RT and does a blocking write to the Xenomai-pipe
> 2) a RT-program that implements a V34 modem is listening to the Xenomai-pipe and will send the data over a telephone line.
> ---> so it is the intention that at startup the Xenomai-pipe buffer gets filled up and from than in stationary state the data should stream at the speed of the V34 modem connection.
>

A typical work-around to emulate blocking Linux -> Xenomai pipe I/O would be:

RT_SEM bsync;

int pipe_i_handler(RT_PIPE *pipe, int event)
{
	if (event == P_EVENT_INPUT && buffer_filled_up_p)
		/* Hold userland until buffer drains. */
		rt_sem_p(&bsync, TM_INFINITE);
	...
}

void drain_buffer(void)
{
	send_v34();
	rt_sem_v(&bsync);
}

void init_kernel_code(void)
{
	rt_sem_create(&bsync, "bsync", 0, S_PULSE);
}

===

void userland(void)
{
	/* Make this regular Linux thread a non-RT Xenomai task, so it may block on
Xenomai synchronization objects. */

	rt_task_shadow(NULL, __FUNCTION__, 0, 0);

	for (;;) {
		/* This may hang in pipe_i_handler() due to flow control. */
		write(pipefd, buf, len);
		...
	}
}

-- 
Philippe.

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Filip Van Rillaer]

Hello,

Thank you for your work-around.
Though I have some problems with the implementation:
pipe_i_handler (Xenomai side) does not know when the xnpipe_write got
errno=ENOMEM (the pipe_i_handler is I think even not called in case
ENOMEM is returned).  So there is I think with the current Xenomai
implementation no way for the pipe_i_handler to correctly fill in the
value of buffer_filled_up_p.  This would mean that my writer-thread
'userland' would have to set this 'variable'.
Then I was thinking about moving the <<rt_sem_p(&bsync, TM_INFINITE)>>
to the writer-thread when errno-ENOMEM is returned, but that would
require that the writer-thread has to bind the semaphore that was
created in another program.  This is probably possible via the Xenomai
registry.

Best regards,
Filip.

-----Original Message-----
From: Philippe Gerum [mailto:rpm@xenomai.org
Sent: 20 August 2008 12:17
To: Filip Van Rillaer
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

Filip Van Rillaer wrote:
> Hello,
> 
> My current test-setup is as follows:
> 1) user-program reads test-samples from a file in non-RT and does a 
> blocking write to the Xenomai-pipe
> 2) a RT-program that implements a V34 modem is listening to the
Xenomai-pipe and will send the data over a telephone line.
> ---> so it is the intention that at startup the Xenomai-pipe buffer
gets filled up and from than in stationary state the data should stream
at the speed of the V34 modem connection.
>

A typical work-around to emulate blocking Linux -> Xenomai pipe I/O
would be:

RT_SEM bsync;

int pipe_i_handler(RT_PIPE *pipe, int event) {
	if (event == P_EVENT_INPUT && buffer_filled_up_p)
		/* Hold userland until buffer drains. */
		rt_sem_p(&bsync, TM_INFINITE);
	...
}

void drain_buffer(void)
{
	send_v34();
	rt_sem_v(&bsync);
}

void init_kernel_code(void)
{
	rt_sem_create(&bsync, "bsync", 0, S_PULSE); }

===

void userland(void)
{
	/* Make this regular Linux thread a non-RT Xenomai task, so it
may block on Xenomai synchronization objects. */

	rt_task_shadow(NULL, __FUNCTION__, 0, 0);

	for (;;) {
		/* This may hang in pipe_i_handler() due to flow
control. */
		write(pipefd, buf, len);
		...
	}
}

--
Philippe.

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Philippe Gerum]

Filip Van Rillaer wrote:
> Hello,
> 
> Thank you for your work-around.
> Though I have some problems with the implementation:
> pipe_i_handler (Xenomai side) does not know when the xnpipe_write got
> errno=ENOMEM (the pipe_i_handler is I think even not called in case
> ENOMEM is returned).

I assumed that you could anticipate the ENOMEM condition knowing the size of the
largest message that could be sent at a time, but ok.

  So there is I think with the current Xenomai
> implementation no way for the pipe_i_handler to correctly fill in the
> value of buffer_filled_up_p.  This would mean that my writer-thread
> 'userland' would have to set this 'variable'.
> Then I was thinking about moving the <<rt_sem_p(&bsync, TM_INFINITE)>>
> to the writer-thread when errno-ENOMEM is returned, but that would
> require that the writer-thread has to bind the semaphore that was
> created in another program.  This is probably possible via the Xenomai
> registry.
>

The patch below calls the monitoring handler with a new event, namely
P_EVENT_FULL, before xnpipe_write() gets -ENOMEM. You would just need to call
rt_sem_p() in that case. Fully untested.

--- include/native/pipe.h	(revision 4105)
+++ include/native/pipe.h	(working copy)
@@ -35,6 +35,7 @@
 #define P_EVENT_INPUT	1
 #define P_EVENT_OUTPUT	2
 #define P_EVENT_CLOSE	3
+#define P_EVENT_FULL	4

 typedef struct rt_pipe_placeholder {
     xnhandle_t opaque;
Index: ksrc/skins/native/pipe.c
===================================================================
--- ksrc/skins/native/pipe.c	(revision 4105)
+++ ksrc/skins/native/pipe.c	(working copy)
@@ -89,9 +89,14 @@
 static void *__pipe_alloc_handler(int bminor, size_t size, void *cookie)
 {
 	RT_PIPE *pipe = (RT_PIPE *)cookie;
+	void *buf;

 	/* Allocate memory for the incoming message. */
-	return xnheap_alloc(pipe->bufpool, size);
+	buf = xnheap_alloc(pipe->bufpool, size);
+	if (buf ==  NULL && pipe->monitor)
+		pipe->monitor(pipe, P_EVENT_FULL);
+
+	return buf;
 }

 static int __pipe_output_handler(int bminor,


> Best regards,
> Filip.
> 
> -----Original Message-----
> From: Philippe Gerum [mailto:rpm@xenomai.org] 
> Sent: 20 August 2008 12:17
> To: Filip Van Rillaer
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM
> 
> Filip Van Rillaer wrote:
>> Hello,
>>
>> My current test-setup is as follows:
>> 1) user-program reads test-samples from a file in non-RT and does a 
>> blocking write to the Xenomai-pipe
>> 2) a RT-program that implements a V34 modem is listening to the
> Xenomai-pipe and will send the data over a telephone line.
>> ---> so it is the intention that at startup the Xenomai-pipe buffer
> gets filled up and from than in stationary state the data should stream
> at the speed of the V34 modem connection.
> 
> A typical work-around to emulate blocking Linux -> Xenomai pipe I/O
> would be:
> 
> RT_SEM bsync;
> 
> int pipe_i_handler(RT_PIPE *pipe, int event) {
> 	if (event == P_EVENT_INPUT && buffer_filled_up_p)
> 		/* Hold userland until buffer drains. */
> 		rt_sem_p(&bsync, TM_INFINITE);
> 	...
> }
> 
> void drain_buffer(void)
> {
> 	send_v34();
> 	rt_sem_v(&bsync);
> }
> 
> void init_kernel_code(void)
> {
> 	rt_sem_create(&bsync, "bsync", 0, S_PULSE); }
> 
> ===
> 
> void userland(void)
> {
> 	/* Make this regular Linux thread a non-RT Xenomai task, so it
> may block on Xenomai synchronization objects. */
> 
> 	rt_task_shadow(NULL, __FUNCTION__, 0, 0);
> 
> 	for (;;) {
> 		/* This may hang in pipe_i_handler() due to flow
> control. */
> 		write(pipefd, buf, len);
> 		...
> 	}
> }
> 
> --
> Philippe.
> 


-- 
Philippe.

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Philippe Gerum]

Filip Van Rillaer wrote:
> Hello,
> 
> Thank you for your work-around.
> Though I have some problems with the implementation:
> pipe_i_handler (Xenomai side) does not know when the xnpipe_write got
> errno=ENOMEM (the pipe_i_handler is I think even not called in case
> ENOMEM is returned).  So there is I think with the current Xenomai
> implementation no way for the pipe_i_handler to correctly fill in the
> value of buffer_filled_up_p.  This would mean that my writer-thread
> 'userland' would have to set this 'variable'.
> Then I was thinking about moving the <<rt_sem_p(&bsync, TM_INFINITE)>>
> to the writer-thread when errno-ENOMEM is returned, but that would
> require that the writer-thread has to bind the semaphore that was
> created in another program.  This is probably possible via the Xenomai
> registry.
>

This patch should be better. We need to retry allocating the buffer once the
monitoring handler has returned with success (i.e. returning 0 causes the retry).

--- include/native/pipe.h	(revision 4105)
+++ include/native/pipe.h	(working copy)
@@ -35,6 +35,7 @@
 #define P_EVENT_INPUT	1
 #define P_EVENT_OUTPUT	2
 #define P_EVENT_CLOSE	3
+#define P_EVENT_FULL	4

 typedef struct rt_pipe_placeholder {
     xnhandle_t opaque;
Index: ksrc/skins/native/pipe.c
===================================================================
--- ksrc/skins/native/pipe.c	(revision 4105)
+++ ksrc/skins/native/pipe.c	(working copy)
@@ -89,9 +89,15 @@
 static void *__pipe_alloc_handler(int bminor, size_t size, void *cookie)
 {
 	RT_PIPE *pipe = (RT_PIPE *)cookie;
+	void *buf;

 	/* Allocate memory for the incoming message. */
-	return xnheap_alloc(pipe->bufpool, size);
+	buf = xnheap_alloc(pipe->bufpool, size);
+	if (buf == NULL && pipe->monitor != NULL &&
+	    pipe->monitor(pipe, P_EVENT_FULL) == 0)
+		buf = xnheap_alloc(pipe->bufpool, size);
+
+	return buf;
 }

 static int __pipe_output_handler(int bminor,

-- 
Philippe.

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Philippe Gerum]

Filip Van Rillaer wrote:
> Hello,
> 
> Thank you for your work-around.
> Though I have some problems with the implementation:
> pipe_i_handler (Xenomai side) does not know when the xnpipe_write got
> errno=ENOMEM (the pipe_i_handler is I think even not called in case
> ENOMEM is returned).  So there is I think with the current Xenomai
> implementation no way for the pipe_i_handler to correctly fill in the
> value of buffer_filled_up_p.  This would mean that my writer-thread
> 'userland' would have to set this 'variable'.
> Then I was thinking about moving the <<rt_sem_p(&bsync, TM_INFINITE)>>
> to the writer-thread when errno-ENOMEM is returned, but that would
> require that the writer-thread has to bind the semaphore that was
> created in another program.  This is probably possible via the Xenomai
> registry.
> 

Commit #4114 provides P_EVENT_NOBUF (formerly P_EVENT_FULL).

-- 
Philippe.

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Filip Van Rillaer]

Hello Philippe,

I updated via svn ... and transferring data to the Xenomai domain with a
pipe now works perfect. I see that also the documentation has been
updated. Thanks a lot, very nice work.

I still have 1 thing on my wish-list of the pipe: is it possible to add
1 argument Cookie (void* or long) to the rt_pipe_monitor function so
that when a generic monitor-function is used, it would be possible to
find it's instance data (that Cookie should then be passed to the
call-back function).
Now I have to work around this as follows:

static rt_vcom_context_t* MonitorCookie[2];
MonitorCookie[0] = &Instance_data_0; rt_pipe_monitor(Pipe0,
MonitorFcts[0]);
MonitorCookie[1] = &Instance_data_1; rt_pipe_monitor(Pipe1,
MonitorFcts[1]);

static int cbMonitor0(RT_PIPE* hPipe, int Event, long Arg) {return
cbMonitor(hPipe, Event, Arg, MonitorCookie[0]);}
static int cbMonitor1(RT_PIPE* hPipe, int Event, long Arg) {return
cbMonitor(hPipe, Event, Arg, MonitorCookie[1]);}
typedef int (*monitor_f)(RT_PIPE *pipe, int event, long arg);
static monitor_f MonitorFcts[SERIAL_NR_DEVS] =
{
   cbMonitor0
  ,cbMonitor1
};

static int cbMonitor(RT_PIPE* hPipe, int Event, long Arg, void* Cookie)
{ /* my generic Monitor implemnetation for all instances */
  rt_vcom_context_t* Mycontext = (rt_vcom_context_t*)Cookie;
  /* .... */
}

However, with an improved version of the Xenomai interface, I would not
need the MonitorFcts array, just:
rt_pipe_monitor(Pipe0, cbMonitor, &Instance_data_0);
rt_pipe_monitor(Pipe1, cbMonitor, &Instance_data_1);

Please comment.


Question concerning P_EVENT_NOBUF.  Now I am using the user-space
endpoint in blocking mode and it works fine with the latest version of
Xenomai when the memory is exhausted.  So far, so good.  But what would
happen if I open the endpoint in non-blocking mode? Would it still be
the implementation of the handler (returning 0) of P_EVENT_NOBUF that
would have the power to block the writer or will the writer then see the
ENOMEM (so indeed non-blocking in all cases)?  Please comment.


Best regards,
Filip.

-----Original Message-----
From: Philippe Gerum [mailto:rpm@xenomai.org
Sent: 20 August 2008 21:08
To: Filip Van Rillaer
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

Filip Van Rillaer wrote:
> Hello,
> 
> Thank you for your work-around.
> Though I have some problems with the implementation:
> pipe_i_handler (Xenomai side) does not know when the xnpipe_write got 
> errno=ENOMEM (the pipe_i_handler is I think even not called in case 
> ENOMEM is returned).  So there is I think with the current Xenomai 
> implementation no way for the pipe_i_handler to correctly fill in the 
> value of buffer_filled_up_p.  This would mean that my writer-thread 
> 'userland' would have to set this 'variable'.
> Then I was thinking about moving the <<rt_sem_p(&bsync, TM_INFINITE)>>

> to the writer-thread when errno-ENOMEM is returned, but that would 
> require that the writer-thread has to bind the semaphore that was 
> created in another program.  This is probably possible via the Xenomai

> registry.
> 

Commit #4114 provides P_EVENT_NOBUF (formerly P_EVENT_FULL).

--
Philippe.

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Philippe Gerum]

Filip Van Rillaer wrote:
> Hello Philippe,
> 
> I updated via svn ... and transferring data to the Xenomai domain with a
> pipe now works perfect. I see that also the documentation has been
> updated. Thanks a lot, very nice work.
>

Both the maintenance and the -devel branches have been updated with changes that
make the non-RT write side block until enough memory is available from the pool
(unless O_NONBLOCK is set). The work-around will still work, but the return
value from the NOBUF event handler is now discarded; the nucleus will retry to
get memory automatically.

> I still have 1 thing on my wish-list of the pipe: is it possible to add
> 1 argument Cookie (void* or long) to the rt_pipe_monitor function so
> that when a generic monitor-function is used, it would be possible to
> find it's instance data (that Cookie should then be passed to the
> call-back function).
> Now I have to work around this as follows:
> 
> static rt_vcom_context_t* MonitorCookie[2];
> MonitorCookie[0] = &Instance_data_0; rt_pipe_monitor(Pipe0,
> MonitorFcts[0]);
> MonitorCookie[1] = &Instance_data_1; rt_pipe_monitor(Pipe1,
> MonitorFcts[1]);
> 
> static int cbMonitor0(RT_PIPE* hPipe, int Event, long Arg) {return
> cbMonitor(hPipe, Event, Arg, MonitorCookie[0]);}
> static int cbMonitor1(RT_PIPE* hPipe, int Event, long Arg) {return
> cbMonitor(hPipe, Event, Arg, MonitorCookie[1]);}
> typedef int (*monitor_f)(RT_PIPE *pipe, int event, long arg);
> static monitor_f MonitorFcts[SERIAL_NR_DEVS] =
> {
>    cbMonitor0
>   ,cbMonitor1
> };
> 
> static int cbMonitor(RT_PIPE* hPipe, int Event, long Arg, void* Cookie)
> { /* my generic Monitor implemnetation for all instances */
>   rt_vcom_context_t* Mycontext = (rt_vcom_context_t*)Cookie;
>   /* .... */
> }
> 
> However, with an improved version of the Xenomai interface, I would not
> need the MonitorFcts array, just:
> rt_pipe_monitor(Pipe0, cbMonitor, &Instance_data_0);
> rt_pipe_monitor(Pipe1, cbMonitor, &Instance_data_1);
> 

cookie args are prone to clutter the API and introduce useless overhead for
carrying them, therefore we don't want to add more of them. The preferred way is
something like:

struct instance {

	RT_PIPE pipe_desc;
};

int handler(RT_PIPE *pipe, int event, long arg)
{
	struct instance *p;

	p = container_of(pipe, RT_PIPE, pipe_desc);
	...
}

I.e. the pipe descriptor can be embodied into the instance structure since there
seem to be a 1:1 relationship, so that the container_of() macro can compute the
address of the containing instance structure from the pointer to the pipe
descriptor.

> Please comment.
> 
> 
> Question concerning P_EVENT_NOBUF.  Now I am using the user-space
> endpoint in blocking mode and it works fine with the latest version of
> Xenomai when the memory is exhausted.  So far, so good.  But what would
> happen if I open the endpoint in non-blocking mode? Would it still be
> the implementation of the handler (returning 0) of P_EVENT_NOBUF that
> would have the power to block the writer or will the writer then see the
> ENOMEM (so indeed non-blocking in all cases)?  Please comment.
> 

O_NONBLOCK would prevent the caller to wait for memory, and cause EWOULDBLOCK to
be returned. There is nothing expected from the NOBUF handler anymore to get
that result. The write() system call will only return ENOMEM in case the buffer
to send is larger than the largest contiguous area of memory available from the
pool, which would mean that the allocation request could never be satisfied.

> 
> Best regards,
> Filip.
> 
> -----Original Message-----
> From: Philippe Gerum [mailto:rpm@xenomai.org] 
> Sent: 20 August 2008 21:08
> To: Filip Van Rillaer
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM
> 
> Filip Van Rillaer wrote:
>> Hello,
>>
>> Thank you for your work-around.
>> Though I have some problems with the implementation:
>> pipe_i_handler (Xenomai side) does not know when the xnpipe_write got 
>> errno=ENOMEM (the pipe_i_handler is I think even not called in case 
>> ENOMEM is returned).  So there is I think with the current Xenomai 
>> implementation no way for the pipe_i_handler to correctly fill in the 
>> value of buffer_filled_up_p.  This would mean that my writer-thread 
>> 'userland' would have to set this 'variable'.
>> Then I was thinking about moving the <<rt_sem_p(&bsync, TM_INFINITE)>>
> 
>> to the writer-thread when errno-ENOMEM is returned, but that would 
>> require that the writer-thread has to bind the semaphore that was 
>> created in another program.  This is probably possible via the Xenomai
> 
>> registry.
>>
> 
> Commit #4114 provides P_EVENT_NOBUF (formerly P_EVENT_FULL).
> 
> --
> Philippe.
> 


-- 
Philippe.

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Filip Van Rillaer]

Hello Philippe,

<<
Both the maintenance and the -devel branches have been updated with
changes that make the non-RT write side block until enough memory is
available from the pool (unless O_NONBLOCK is set). The work-around will
still work, but the return value from the NOBUF event handler is now
discarded; the nucleus will retry to get memory automatically.
>>
Thanks.

<<
cookie args are prone to clutter the API and introduce useless overhead
for carrying them, therefore we don't want to 
add more of them. The preferred way is something like: ...
>>
Yes, you are right, I will update my code following your advice.  Thanks
for investigating my case.

Best regards,
Filip

Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM

[Philippe Gerum]

Filip Van Rillaer wrote:
> Hello,
> 
> My current test-setup is as follows:
> 1) user-program reads test-samples from a file in non-RT and does a blocking write to the Xenomai-pipe
> 2) a RT-program that implements a V34 modem is listening to the Xenomai-pipe and will send the data over a telephone line.
> ---> so it is the intention that at startup the Xenomai-pipe buffer gets filled up and from than in stationary state the data should stream at the speed of the V34 modem connection.
> 
> The RT-side is using rt_pipe_monitor to be warned when new data from the non-RT write arrives (so no polling).  The RT-side will 'remember' that data from the non-RT side are available and (sometimes a lot) later when enough data have been sent over the telephone line, read new data from the Xenomai pipe.
> 
> Any idea how I can get around this problem?
> 
> Concerning O_SYNC I get the fatal error message:
>  Xenomai: fatal: inserting element twice, holder=00b19cfc, qslot=00b1ab84 at kernel/xenomai/nucleus/pipe.c:96
>   CPU  PID    PRI      TIMEOUT  STAT      NAME
>  >  0  0       -1      0        00400080  ROOT
>     0  112     99      999616310 00300186  RTTask
> I think that this happens around the same time that I get the -ENOMEM when I am not using the O_SYNC flag.
>

Fixed in both the -devel and maintenance branches.

> Best regards,
> Filip
>  
> 
> -----Original Message-----
> From: Philippe Gerum [mailto:rpm@xenomai.org] 
> Sent: 19 August 2008 18:31
> To: Filip Van Rillaer
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM
> 
> Filip Van Rillaer wrote:
>> Hello,
>>  
>> I am opening the uClinux side of a Xenomai pipe like (so in blocking mode):
>> FdPipe = open(PipeName, O_RDWR);
>> After some writes to FdPipe I get the returnvalue -ENOMEM.
>> I can understand that the internal buffer gets full as my application 
>> is writing data faster than the Xenomai side is consuming, but I don't 
>> expect to see a returnvalue -ENOMEM : the calling writing-thread 
>> should block, isn't it?  Please comment.
>>
> 
> RT is assumed to consume asap and will preempt the non-RT write() caller immediately upon data receipt, unless the RT code uses some kind of timed polling, which is considered useless and inefficient, since you can ask a RT thread to wait for incoming data in a blocking way.
> 
>> (When adding the O_SYNC flag things get even worse)
>>  
> 
> That is the point that would actually need fixing: what happens with O_SYNC, what is worsening exactly?
> 
>> Why is the code for xnpipe_write saying:
>> if (!mh)
>>   /* Cannot sleep. */   <--- ???????????????????
>>   return -ENOMEM;
>>  
>> I am using svn version 4105.
>>  
>> Best regards,
>> Filip
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
> 
> 
> --
> Philippe.
> 


-- 
Philippe.