All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-core] Fixing xeno-test
@ 2009-04-14  1:55 Martin Shepherd
  2009-04-14 13:15 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 3+ messages in thread
From: Martin Shepherd @ 2009-04-14  1:55 UTC (permalink / raw)
  To: xenomai

I have been working on fixing the problems in xeno-test that I
reported a few days ago. After spending most of yesterday fighting
with the broken signal-handling behavior of the various bourne-shell
derivatives, I came to the conclusion that it was impossible to
reliably and portably clean up background workload processes using
just shell signal handling. I thus decided to write a separate program
that xeno-test could invoke, which would take care of running the
background processes, restart any that terminated before xeno-test
ended, and terminate them when xeno-test either exited normally or was
terminated by a signal. I have done this now, incorporated it into
xeno-test, and tested it while running xeno-test under bash, dash and
busybox. My question is whether this approach is acceptible, and if
so, how I should submit it for incorporation in xenomai?

In particular, for the program that manages the background workload
processes (which is currently called xeno-stress), should I create a
new directory for this under xenomai-head/src/testsuite/, and set up
makefiles etc there, or should it go somewhere else?

In case anybody wants to see the code first, you can find the program
source code and a simple makefile for compiling it, at:

   http://www.astro.caltech.edu/~mcs/xenomai/xeno-stress.c
   http://www.astro.caltech.edu/~mcs/xenomai/Makefile

It is run like:

   ./xeno-stress -n 2 -r 100 dd if=/dev/zero of=/dev/null &

where -n 2 means run two copies of the workload process, -r 100 means
don't restart the workload processes more than 100 times, and the
workload program and its arguments are the trailing arguments given to
xeno-stress. In the above case this is xeno-test's conventional dd
workload. Sending the xeno-stress process any TERM, INT, PIPE, HUP or
QUIT signal will cause it to terminate the workload processes that it
started. To avoid race conditions, it uses 2 threads; one which starts
the workload processes, then sits in wait(), restarting any processes
that end normally, or exiting if any end abnormally, and a second that
sits in sigwait(), watching for termination signals, and when one is
received, terminating all of the background processes before telling
the other thread to terminate itself.

Martin


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Xenomai-core] Fixing xeno-test
  2009-04-14  1:55 [Xenomai-core] Fixing xeno-test Martin Shepherd
@ 2009-04-14 13:15 ` Gilles Chanteperdrix
  2009-04-14 18:29   ` Martin Shepherd
  0 siblings, 1 reply; 3+ messages in thread
From: Gilles Chanteperdrix @ 2009-04-14 13:15 UTC (permalink / raw)
  To: Martin Shepherd; +Cc: xenomai

Martin Shepherd wrote:
> I have been working on fixing the problems in xeno-test that I
> reported a few days ago. After spending most of yesterday fighting
> with the broken signal-handling behavior of the various bourne-shell
> derivatives, I came to the conclusion that it was impossible to
> reliably and portably clean up background workload processes using
> just shell signal handling. I thus decided to write a separate program
> that xeno-test could invoke, which would take care of running the
> background processes, restart any that terminated before xeno-test
> ended, and terminate them when xeno-test either exited normally or was
> terminated by a signal. I have done this now, incorporated it into
> xeno-test, and tested it while running xeno-test under bash, dash and
> busybox. My question is whether this approach is acceptible, and if
> so, how I should submit it for incorporation in xenomai?

I'd prefer to avoid adding this new program. xeno-test is already more
complicated than I would like, and I am almost sure that we can handle
differences between the shells by testing what shell we are running (for
instance using the SHELL variable) and using some explicit "ifs" in the
script.

> 
> In particular, for the program that manages the background workload
> processes (which is currently called xeno-stress), should I create a
> new directory for this under xenomai-head/src/testsuite/, and set up
> makefiles etc there, or should it go somewhere else?
> 
> In case anybody wants to see the code first, you can find the program
> source code and a simple makefile for compiling it, at:
> 
>    http://www.astro.caltech.edu/~mcs/xenomai/xeno-stress.c

I get a 404.

-- 
                                                 Gilles.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Xenomai-core] Fixing xeno-test
  2009-04-14 13:15 ` Gilles Chanteperdrix
@ 2009-04-14 18:29   ` Martin Shepherd
  0 siblings, 0 replies; 3+ messages in thread
From: Martin Shepherd @ 2009-04-14 18:29 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai


On Tue, 14 Apr 2009, Gilles Chanteperdrix wrote:
> I'd prefer to avoid adding this new program. xeno-test is already more
> complicated than I would like, and I am almost sure that we can handle
> differences between the shells by testing what shell we are running (for
> instance using the SHELL variable) and using some explicit "ifs" in the
> script.

Okay, although the external C program was meant to simplify the
xeno-test script. I'll have another look at doing this entirely in the
shell.

>> In case anybody wants to see the code first, you can find the program
>> source code and a simple makefile for compiling it, at:
>>
>>    http://www.astro.caltech.edu/~mcs/xenomai/xeno-stress.c
>
> I get a 404.

Sorry, I must have deleted the wrong file after accidentally placing
it in 2 places. FWIW, I've put it back now.

Martin


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-04-14 18:29 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-04-14  1:55 [Xenomai-core] Fixing xeno-test Martin Shepherd
2009-04-14 13:15 ` Gilles Chanteperdrix
2009-04-14 18:29   ` Martin Shepherd

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.