* Re: [Xenomai-help] rtcanrecv output line-buffering [not found] <4DF934BD.50505@domain.hid> @ 2011-06-16 15:20 ` Andrew Tannenbaum 2011-06-27 7:48 ` Wolfgang Grandegger [not found] ` <261CC64699FF40F2937C31EEF248B8E5@domain.hid> 0 siblings, 2 replies; 4+ messages in thread From: Andrew Tannenbaum @ 2011-06-16 15:20 UTC (permalink / raw) To: xenomai I was trying to use the Xenomai RT-Socket-CAN rtcanrecv in a Tcl/Tk script GUI wrapper. rtcanrecv uses printf to stdout, and it line-buffers when attached to a tty, but it uses larger buffers (so it is unusable) when run from a script with no tty. Tcl does stdio with pipes rather than ptys (that is, Tcl thinks it has no tty for stdio). I think both bash and perl use ptys (and so don't have this problem). I haven't done a more thorough survey, but that's not the point. I think it would be nice to modify rtcanrecv so it can write stdout in line-buffered mode. If you think this is a good idea, please either set line buffering with setvbuf(stdout, NULL, _IOLBF, 0); at the top of src/utils/can/rtcanrecv.c:rt_task() or fflush(stdout); after the printf("\n") at the bottom of rt_task(), or you could add a command line getopt option for line-buffering that would do one of the above. -Andy ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xenomai-help] rtcanrecv output line-buffering 2011-06-16 15:20 ` [Xenomai-help] rtcanrecv output line-buffering Andrew Tannenbaum @ 2011-06-27 7:48 ` Wolfgang Grandegger [not found] ` <261CC64699FF40F2937C31EEF248B8E5@domain.hid> 1 sibling, 0 replies; 4+ messages in thread From: Wolfgang Grandegger @ 2011-06-27 7:48 UTC (permalink / raw) To: Andrew Tannenbaum; +Cc: xenomai On 06/16/2011 05:20 PM, Andrew Tannenbaum wrote: > I was trying to use the Xenomai RT-Socket-CAN rtcanrecv in a Tcl/Tk > script GUI wrapper. > > rtcanrecv uses printf to stdout, and it line-buffers when attached to a > tty, but it uses larger buffers (so it is unusable) when run from a > script with no tty. > > Tcl does stdio with pipes rather than ptys (that is, Tcl thinks it has > no tty for stdio). I think both bash and perl use ptys (and so don't > have this problem). I haven't done a more thorough survey, but that's > not the point. > > I think it would be nice to modify rtcanrecv so it can write stdout in > line-buffered mode. If you think this is a good idea, please either set > line buffering with > > setvbuf(stdout, NULL, _IOLBF, 0); > > at the top of src/utils/can/rtcanrecv.c:rt_task() or > > fflush(stdout); > > after the printf("\n") at the bottom of rt_task(), or you could add a > command line getopt option for line-buffering that would do one of the > above. I would prefer the latter, patches are welcome. Be aware that using printf will switch to secondary mode which should be avoided if real-time is required. Wolfgang. ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <261CC64699FF40F2937C31EEF248B8E5@domain.hid>]
* Re: [Xenomai-help] rtcanrecv output line-buffering [not found] ` <261CC64699FF40F2937C31EEF248B8E5@domain.hid> @ 2011-06-27 17:39 ` Andrew Tannenbaum 2011-06-28 20:31 ` Gilles Chanteperdrix 0 siblings, 1 reply; 4+ messages in thread From: Andrew Tannenbaum @ 2011-06-27 17:39 UTC (permalink / raw) To: Wolfgang Grandegger; +Cc: xenomai [-- Attachment #1: Type: text/plain, Size: 1928 bytes --] Wolfgang Grandegger wrote: > On 06/16/2011 05:20 PM, Andrew Tannenbaum wrote: >> I was trying to use the Xenomai RT-Socket-CAN rtcanrecv in a Tcl/Tk >> script GUI wrapper. >> >> rtcanrecv uses printf to stdout, and it line-buffers when attached to a >> tty, but it uses larger buffers (so it is unusable) when run from a >> script with no tty. >> >> Tcl does stdio with pipes rather than ptys (that is, Tcl thinks it has >> no tty for stdio). I think both bash and perl use ptys (and so don't >> have this problem). I haven't done a more thorough survey, but that's >> not the point. >> >> I think it would be nice to modify rtcanrecv so it can write stdout in >> line-buffered mode. If you think this is a good idea, please either set >> line buffering with >> >> setvbuf(stdout, NULL, _IOLBF, 0); >> >> at the top of src/utils/can/rtcanrecv.c:rt_task() or >> >> fflush(stdout); >> >> after the printf("\n") at the bottom of rt_task(), or you could add a >> command line getopt option for line-buffering that would do one of the >> above. > > I would prefer the latter, patches are welcome. Be aware that using > printf will switch to secondary mode which should be avoided if > real-time is required. > > Wolfgang. > Wolfgang, rtcanrecv already exists using printf, I'm just changing the buffering. I added a -L (line-buffer) getopt switch (default=off), as you suggested. I added it to the C source and the man page. Attached are two diff patch files, one for rtcanrecv.c and one for rtcanrecv.man.in . I see there is a generated version of the html man page in the tar file, I assume that is created automatically, so I didn't patch it. I created the patches within the folders containing the source files, and I diffed from filenames foo.orig to foo. I am not aware of the naming protocol for patches in the development tree, but these are simple patches so I hope they are sufficient. -Andy [-- Attachment #2: rtcanrecv.c.patch --] [-- Type: text/x-patch, Size: 1585 bytes --] --- rtcanrecv.c.orig 2011-06-27 12:02:43.634343171 -0400 +++ rtcanrecv.c 2011-06-27 12:12:32.834332555 -0400 @@ -24,6 +24,7 @@ " -R, --timestamp-rel with relative timestamp\n" " -v, --verbose be verbose\n" " -p, --print=MODULO print every MODULO message\n" + " -L, --line-buffer use line buffering\n" " -h, --help this help\n", prg); } @@ -31,7 +32,7 @@ extern int optind, opterr, optopt; -static int s = -1, verbose = 0, print = 1; +static int s = -1, verbose = 0, print = 1, line_buffer = 0; static nanosecs_rel_t timeout = 0, with_timestamp = 0, timestamp_rel = 0; RT_TASK rt_task_desc; @@ -174,6 +175,7 @@ { "timeout", required_argument, 0, 't'}, { "timestamp", no_argument, 0, 'T'}, { "timestamp-rel", no_argument, 0, 'R'}, + { "line-buffer", no_argument, 0, 'L'}, { 0, 0, 0, 0}, }; @@ -182,7 +184,7 @@ signal(SIGTERM, cleanup_and_exit); signal(SIGINT, cleanup_and_exit); - while ((opt = getopt_long(argc, argv, "hve:f:t:p:RT", + while ((opt = getopt_long(argc, argv, "hve:f:t:p:RTL", long_options, NULL)) != -1) { switch (opt) { case 'h': @@ -230,6 +232,10 @@ with_timestamp = 1; break; + case 'L': + line_buffer = 1; + break; + default: fprintf(stderr, "Unknown option %c\n", opt); break; @@ -311,6 +317,10 @@ } } + if (line_buffer) { + setvbuf(stdout, NULL, _IOLBF, 0); + } + snprintf(name, sizeof(name), "rtcanrecv-%d", getpid()); ret = rt_task_shadow(&rt_task_desc, name, 0, 0); if (ret) { [-- Attachment #3: rtcanrecv.man.in.patch --] [-- Type: text/x-patch, Size: 307 bytes --] --- rtcanrecv.man.in.orig 2011-06-27 13:19:28.558330768 -0400 +++ rtcanrecv.man.in 2011-06-27 13:20:27.798334902 -0400 @@ -46,6 +46,9 @@ .B \-p, \-\-print=MODULO print every MODULO message .TP +.B \-L, \-\-line-buffer +flush buffered ouput for each line +.TP .B \-h, \-\-help this help .SH "SEE ALSO" ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xenomai-help] rtcanrecv output line-buffering 2011-06-27 17:39 ` Andrew Tannenbaum @ 2011-06-28 20:31 ` Gilles Chanteperdrix 0 siblings, 0 replies; 4+ messages in thread From: Gilles Chanteperdrix @ 2011-06-28 20:31 UTC (permalink / raw) To: Andrew Tannenbaum; +Cc: xenomai On 06/27/2011 07:39 PM, Andrew Tannenbaum wrote: > Wolfgang Grandegger wrote: >> On 06/16/2011 05:20 PM, Andrew Tannenbaum wrote: >>> I was trying to use the Xenomai RT-Socket-CAN rtcanrecv in a Tcl/Tk >>> script GUI wrapper. >>> >>> rtcanrecv uses printf to stdout, and it line-buffers when attached to a >>> tty, but it uses larger buffers (so it is unusable) when run from a >>> script with no tty. >>> >>> Tcl does stdio with pipes rather than ptys (that is, Tcl thinks it has >>> no tty for stdio). I think both bash and perl use ptys (and so don't >>> have this problem). I haven't done a more thorough survey, but that's >>> not the point. >>> >>> I think it would be nice to modify rtcanrecv so it can write stdout in >>> line-buffered mode. If you think this is a good idea, please either set >>> line buffering with >>> >>> setvbuf(stdout, NULL, _IOLBF, 0); >>> >>> at the top of src/utils/can/rtcanrecv.c:rt_task() or >>> >>> fflush(stdout); >>> >>> after the printf("\n") at the bottom of rt_task(), or you could add a >>> command line getopt option for line-buffering that would do one of the >>> above. >> >> I would prefer the latter, patches are welcome. Be aware that using >> printf will switch to secondary mode which should be avoided if >> real-time is required. >> >> Wolfgang. >> > > Wolfgang, > > rtcanrecv already exists using printf, I'm just changing the buffering. > I added a -L (line-buffer) getopt switch (default=off), as you > suggested. I added it to the C source and the man page. > > Attached are two diff patch files, one for rtcanrecv.c and one for > rtcanrecv.man.in . I see there is a generated version of the html man > page in the tar file, I assume that is created automatically, so I > didn't patch it. I created the patches within the folders containing > the source files, and I diffed from filenames foo.orig to foo. I am not > aware of the naming protocol for patches in the development tree, but > these are simple patches so I hope they are sufficient. Hi, These patches look fine though we prefer usually to generate them such that they can be applied with patch -p1. git makes them that way. Anyway, Wolfgang, if you are OK with the patches I will merge them. -- Gilles. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-06-28 20:31 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4DF934BD.50505@domain.hid>
2011-06-16 15:20 ` [Xenomai-help] rtcanrecv output line-buffering Andrew Tannenbaum
2011-06-27 7:48 ` Wolfgang Grandegger
[not found] ` <261CC64699FF40F2937C31EEF248B8E5@domain.hid>
2011-06-27 17:39 ` Andrew Tannenbaum
2011-06-28 20:31 ` Gilles Chanteperdrix
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.