From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C90217.B0FB3F54" Date: Tue, 19 Aug 2008 18:21:52 +0200 Message-ID: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> From: "Filip Van Rillaer" Subject: [Xenomai-help] uClinux write to pipe returning -ENOMEM List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C90217.B0FB3F54 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I am opening the uClinux side of a Xenomai pipe like (so in blocking mode): FdPipe =3D 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. =20 (When adding the O_SYNC flag things get even worse) =20 Why is the code for xnpipe_write saying: if (!mh)=20 /* Cannot sleep. */ <--- ??????????????????? return -ENOMEM; =20 I am using svn version 4105. =20 Best regards, Filip ------_=_NextPart_001_01C90217.B0FB3F54 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I am = opening the=20 uClinux side of a Xenomai pipe like (so in blocking=20 mode):

FdPipe = =3D=20 open(PipeName, O_RDWR);

After = some writes to=20 FdPipe I get the returnvalue -ENOMEM.

I can = understand=20 that the internal buffer gets full as my application is writing data = faster than=20 the Xenomai side is consuming, but I don't expect to see a returnvalue = -ENOMEM :=20 the calling writing-thread should block, isn't it? Please=20 comment.

(When = adding the=20 O_SYNC flag things get even worse)

Why is = the code for=20 xnpipe_write saying:

if = (!mh)=20

= /* Cannot=20 sleep. */ <--- ???????????????????

= return=20 -ENOMEM;

I am = using=20 svn version 4105.

Best=20 regards,

Filip

------_=_NextPart_001_01C90217.B0FB3F54-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48AAF55E.9000206@domain.hid> Date: Tue, 19 Aug 2008 18:31:26 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> In-Reply-To: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Van Rillaer Cc: xenomai@xenomai.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48ABE84B.7070803@domain.hid> Date: Wed, 20 Aug 2008 11:47:55 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> <48AAF55E.9000206@domain.hid> <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> In-Reply-To: <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Van Rillaer Cc: xenomai@xenomai.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48ABEF11.6060307@domain.hid> Date: Wed, 20 Aug 2008 12:16:49 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> <48AAF55E.9000206@domain.hid> <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> In-Reply-To: <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Van Rillaer Cc: xenomai@xenomai.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Aug 2008 17:04:09 +0200 Message-ID: <406CC9939904F143B9D42CEEA3E56E56432116@domain.hid> References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> <48AAF55E.9000206@domain.hid> <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> <48ABEF11.6060307@domain.hid> From: "Filip Van Rillaer" Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai@xenomai.org 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=3DENOMEM (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 <> 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, >=20 > My current test-setup is as follows: > 1) user-program reads test-samples from a file in non-RT and does a=20 > 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 =3D=3D 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); } =3D=3D=3D 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48AC4F2F.3030508@domain.hid> Date: Wed, 20 Aug 2008 19:06:55 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> <48AAF55E.9000206@domain.hid> <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> <48ABEF11.6060307@domain.hid> <406CC9939904F143B9D42CEEA3E56E56432116@domain.hid> In-Reply-To: <406CC9939904F143B9D42CEEA3E56E56432116@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Van Rillaer Cc: xenomai@xenomai.org 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 <> > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48AC4DB5.1060305@domain.hid> Date: Wed, 20 Aug 2008 19:00:37 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> <48AAF55E.9000206@domain.hid> <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> <48ABEF11.6060307@domain.hid> <406CC9939904F143B9D42CEEA3E56E56432116@domain.hid> In-Reply-To: <406CC9939904F143B9D42CEEA3E56E56432116@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Van Rillaer Cc: xenomai@xenomai.org 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 <> > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48AC6BA0.9010306@domain.hid> Date: Wed, 20 Aug 2008 21:08:16 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> <48AAF55E.9000206@domain.hid> <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> <48ABEF11.6060307@domain.hid> <406CC9939904F143B9D42CEEA3E56E56432116@domain.hid> In-Reply-To: <406CC9939904F143B9D42CEEA3E56E56432116@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Van Rillaer Cc: xenomai@xenomai.org 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 <> > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Aug 2008 13:08:13 +0200 Message-ID: <406CC9939904F143B9D42CEEA3E56E56432274@domain.hid> References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> <48AAF55E.9000206@domain.hid> <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> <48ABEF11.6060307@domain.hid> <406CC9939904F143B9D42CEEA3E56E56432116@domain.hid> <48AC6BA0.9010306@domain.hid> From: "Filip Van Rillaer" Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai@xenomai.org 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] =3D &Instance_data_0; rt_pipe_monitor(Pipe0, MonitorFcts[0]); MonitorCookie[1] =3D &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] =3D { 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 =3D (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, >=20 > 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=20 > errno=3DENOMEM (the pipe_i_handler is I think even not called in case=20 > ENOMEM is returned). So there is I think with the current Xenomai=20 > implementation no way for the pipe_i_handler to correctly fill in the=20 > value of buffer_filled_up_p. This would mean that my writer-thread=20 > 'userland' would have to set this 'variable'. > Then I was thinking about moving the <> > to the writer-thread when errno-ENOMEM is returned, but that would=20 > require that the writer-thread has to bind the semaphore that was=20 > created in another program. This is probably possible via the Xenomai > registry. >=20 Commit #4114 provides P_EVENT_NOBUF (formerly P_EVENT_FULL). -- Philippe. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48AF03A0.9000909@domain.hid> Date: Fri, 22 Aug 2008 20:21:20 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> <48AAF55E.9000206@domain.hid> <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> In-Reply-To: <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Van Rillaer Cc: xenomai@xenomai.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48AF0378.3030001@domain.hid> Date: Fri, 22 Aug 2008 20:20:40 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> <48AAF55E.9000206@domain.hid> <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> <48ABEF11.6060307@domain.hid> <406CC9939904F143B9D42CEEA3E56E56432116@domain.hid> <48AC6BA0.9010306@domain.hid> <406CC9939904F143B9D42CEEA3E56E56432274@domain.hid> In-Reply-To: <406CC9939904F143B9D42CEEA3E56E56432274@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Van Rillaer Cc: xenomai@xenomai.org 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 <> > >> 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Aug 2008 08:30:53 +0200 Message-ID: <406CC9939904F143B9D42CEEA3E56E564324F6@domain.hid> References: <406CC9939904F143B9D42CEEA3E56E56431F57@domain.hid> <48AAF55E.9000206@domain.hid> <406CC9939904F143B9D42CEEA3E56E56431FCD@oab1mx1.oneaccess.intra> <48ABEF11.6060307@domain.hid> <406CC9939904F143B9D42CEEA3E56E56432116@domain.hid> <48AC6BA0.9010306@domain.hid> <406CC9939904F143B9D42CEEA3E56E56432274@domain.hid> <48AF0378.3030001@domain.hid> From: "Filip Van Rillaer" Subject: Re: [Xenomai-help] uClinux write to pipe returning -ENOMEM List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai@xenomai.org 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=20 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