Re^3: testing of named pipes

Update: after explicitelly triggering the Event loop after each write to the pipes, things seem to work fine. I will make a more detailed check this evening.

sub testSequence ()
{
   my $appControlFifo;
   my $deviceControlFifo; 
   if ('' eq (-p "$sm->{config}->{deviceControl}" ))
   {
      POSIX::mkfifo ("$sm->{config}->{deviceControl}", 0700);
   }
  # shorthands for pipe handles
   open ($appControlFifo, "+>", $sm->{config}->{fifoControl}->{control
+}) || die "Could not open status pipe for writing ($!)\n";
   open ($deviceControlFifo, "+>", $sm->{config}->{deviceControl}) || 
+die "Could not open status pipe for writing ($!)\n";
   $| = 1;
   $appControlFifo->autoflush(1);
   $deviceControlFifo->autoflush(1);
   # test sequence
   print $appControlFifo "connect to device\n"; # state transition: 01
+ -> 02, currently automatically set
   Event::one_event();
   print $deviceControlFifo "^MODE:1,1\n";      # state transition: 02
+ -> 03
   Event::one_event();
   print "State Instance:>>> " . $sm->Instance() . "\n";
   if ($sm->Instance() =~ "Statemachine::03")   # check if transition 
+succeeded (kind of ASSERT)
   {
      print "transition succeeded\n";
   }
   print $appControlFifo "connect to internet\n"; # state transition: 
+03 -> 04
   Event::one_event();
   print $appControlFifo "internet connected\n"; # state transition: 0
+3 -> 04
   Event::one_event();
}
[download]

Comment on Re^3: testing of named pipes Download Code

Replies are listed 'Best First'.
Re^4: testing of named pipes by jcb (Parson) on Aug 27, 2019 at 23:05 UTC
A named pipe (FIFO) is meant to be opened twice, once for reading only and once for writing only. Generally, the two ends of a named pipe are expected to be opened by different processes although it should still work if one process opens both. At the least, you should `fork` at the beginning of `testSequence` and have the parent return immediately to the event loop. (You will have to handle synchronization for completing the test and reporting a result back to the parent separately; `pipe` is likely to be useful for this and I have used it in a number of `Tk` programs to handle slow background tasks in child processes without blocking the GUI thread.) This will effectively require another event-driven task in the parent to verify the state machine behavior as the child makes incremental progress reports, since the test driver and FSM will be in separate processes. If you insist on your current approach, inserting recursive calls to the event loop to process the events you create in `testSequence` is exactly what you must do.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: testing of named pipes
by jcb (Parson) on Aug 27, 2019 at 23:05 UTC

A named pipe (FIFO) is meant to be opened twice, once for reading only and once for writing only. Generally, the two ends of a named pipe are expected to be opened by different processes although it should still work if one process opens both.

At the least, you should fork at the beginning of testSequence and have the parent return immediately to the event loop. (You will have to handle synchronization for completing the test and reporting a result back to the parent separately; pipe is likely to be useful for this and I have used it in a number of Tk programs to handle slow background tasks in child processes without blocking the GUI thread.) This will effectively require another event-driven task in the parent to verify the state machine behavior as the child makes incremental progress reports, since the test driver and FSM will be in separate processes.

If you insist on your current approach, inserting recursive calls to the event loop to process the events you create in testSequence is exactly what you must do.

[reply]
[d/l]
[select]