[Xenomai-help] Posix skin and message queues operation mode misunderstanding

[Xenomai-help] Posix skin and message queues operation mode misunderstanding

[juanba romance]

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

Hello all i am trying to use a POSIX message queue object to interface a
couple of application modules and  i am fully confused.

The execution environment is configured with a fully operational
xenomai-2.4.2 /linux 2.6.24-2 framework

First at all a test program is written/assembled using the librt stuff
without any xenomai component in order to check the "standard POSIX"
behavior
The program works in two modes via input switches
the "r" mode creates a POSIX queue and attach a notifier through the method
SIGEV_THREAD, the main sleeps a while before close the created object
for each callback the notifier empties the queue dumping the values and
register again the callback symbol up to main flow is timed out .
the "w" mode tries to push a pattern data set into the created queue in
burst mode
So one pid empties the queue and the other apply data. The linux domain
version using the librt works at expected.

The weird thing is when we compile the stuff using the xeno-config switches
so we build xenomai domain message queues..
Such stuff doesn't provide any feedback to the notifier symbol of the reader
PID ??
The writer PID however doesn't provide any error relative to queue open/send
system calls

It seems that i am misunderstanding something really basic when these
objects are applied on the Xenomai domain.

Could somebody provide me any hint ?

I attach the test-program below, the stuff is assembled with:
(Standard case ) gcc -Wall mqueue_test.c -o mqueue_test.x -lrt
( Xenomai one  ) gcc -Wall mqueue_test.c `xeno-config --xeno-cflags
--posix-cflags` `xeno-config --xeno-ldflags --posix-ldflags` -o
mqueue_test.x

Cheers

#include <stdlib.>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <mqueue.h>
#include <getopt.h>
#include <unistd.h>
#include <signal.h>

#define __PROBE_QUEUE "/probe-queue"

static void  aux_channel_callback( sigval_t sigval );
static void *attach_writer( );
static void *attach_reader( );
static void helper( char **argv );

static struct sigevent callback_spec = {
  .sigev_notify = SIGEV_THREAD,
  .sigev_notify_function = aux_channel_callback,
  .sigev_notify_attributes = NULL
};
static char mqname[32];
static int no_messages = 0;
static int operation_mode = -1;

typedef enum t_operation_mode{
  __READER_MODE,
  __WRITER_MODE
}t_operation_mode;


static void aux_channel_callback( sigval_t sigval ){
  mqd_t *mqd;
  unsigned priority;
  int value, so_data;

  mqd = ( mqd_t* )( sigval.sival_int );

  do{
    so_data = mq_receive( *mqd, ( void* )( & value ), sizeof( int ), &
priority );
    if( so_data < 0 ){
      printf("%s: %s\n", __func__ , strerror( errno ) );
      break;
    }
    else if ( so_data == 0 )
      break;
    else if( so_data != sizeof( int ) ){
      printf("\n%s: Expected %d versus %d\n", __func__ , so_data, sizeof(
int ) );
      break;
    }
    else
      printf("%d: %s(%d): received value $%08x\n", getpid( ),  __func__ ,
++no_messages, value );
  }while( 1 );

  if( mq_notify( *mqd, ( const struct sigevent* )( & callback_spec ) ) < 0 )
    printf("%s: notify registering FAILURE: %s\n", __func__ , strerror(
errno ) );

  printf("%d: %s T R I G G E R E D\n", getpid( ), __func__ );
  fflush( stdout );
  return;

}


static void helper( char **argv ){

  printf("\n%s usage:\n", argv[ 0 ] );
  printf("\t%-20s: %-20s\n", "-h, --help", "This help");
  printf("\t%-20s: %-20s\n", "-m, --mode", "(w)Writer mode/(r)Reader mode
using notifications based on SIGEV_THREAD" );
  printf("\t%-20s: %-20s\n", "-l, --loop", "the writer loop" );
  fflush( stdout );

}


int main( int argc, char **argv ){
  int c, no_iterations = 1, i, probe_value = 0xdeadbeef;
  extern char *optarg;
  mqd_t *mqd = NULL;
  struct option long_options[] = {
    { "help"  , no_argument, 0, 'h' },
    { "mode", required_argument, 0, 'm'},
    { "loop"  , required_argument, 0, 'l'},
    { 0, 0, 0, 0},
  };

  while ( ( c = getopt_long( argc, argv, "hm:l:",  long_options, NULL )) !=
EOF ){
    switch(c){

    case 'h':
    default:
      helper( argv );
      return( 0 );
      break;

    case 'm' :
      if( *optarg == 'w' ){
    operation_mode = __WRITER_MODE;
    if( ( mqd = ( mqd_t* )attach_writer( ) ) == NULL )
      return( -1 );
      }
      else if ( *optarg == 'r' ){
    operation_mode = __READER_MODE;
    if( ( mqd = ( mqd_t* )attach_reader( ) ) == NULL )
      return( -1 );
      }
      break;

    case 'l':
      no_iterations = atoi( optarg );
      break;
    }
  }

  printf( "%s: test selected: %s", __func__ ,
      operation_mode == __WRITER_MODE ? "W R I T E R" :
      operation_mode == __READER_MODE ? "R E A D E R" : "U N K N O W N" );

  switch( operation_mode ){
  default:
    helper( argv );
    return( -1 );

  case __WRITER_MODE:
    if( mqd ){
      printf( "\n\t%d iterations using pattern $%08x\n", no_iterations,
probe_value );
      fflush( stdout );
      for( i = 0; i < no_iterations; i++ ){
    if( mq_send( *mqd, ( void* )( & probe_value ), sizeof( probe_value ), 0
) < 0 ){
      printf("%s: %d.%d to queue %s: %s\n",
         __func__ , i, probe_value, mqname, strerror( errno ) );
      break;
    }
    probe_value = ~ probe_value;
      }
    }
    break;

  case __READER_MODE:
    printf( "\n\t%s wait activity\n", __func__ );
    fflush( stdout );
    sleep( 200 );
    break;
  }

  if( mqd )
    mq_close( *mqd );
  return( 1 );

}


static void* attach_writer( ){
   static mqd_t mqd;

   snprintf( mqname, sizeof( mqname ), __PROBE_QUEUE );
   mqd = mq_open( mqname, O_WRONLY );
   if( mqd == ( mqd_t )( -1 ) ){
     printf("%s: OPEN queue %s: %s\n", __func__ , mqname, strerror( errno )
);
     fflush( stdout );
     return( NULL );
   }
   return( ( void* )( & mqd ) );

}


static void* attach_reader( ){
  struct mq_attr mqattr;
  static mqd_t mqd;

  mqattr.mq_flags   = 0;
  mqattr.mq_maxmsg  = 100;
  mqattr.mq_msgsize = sizeof( int );
  snprintf( mqname, sizeof( mqname ), __PROBE_QUEUE );
  mqd = mq_open( mqname,  O_RDONLY| O_CREAT| O_EXCL, 0666, & mqattr );
  if( mqd == ( mqd_t )( -1 )  ){
    printf("%s: %s %s: ", __func__ , mqname, strerror( errno ) );
    if( errno == EEXIST ){
      printf("cleaning stuff" );
      mq_unlink( __PROBE_QUEUE );
    }
    printf("\n" );
    fflush( stdout );
    return( ( void* )NULL );

  }
  else{
    callback_spec.sigev_value.sival_int = ( int )( & mqd );
    if( mq_notify( mqd, ( const struct sigevent* )( & callback_spec ) ) < 0
){
      printf("%s: notify registering FAILURE: %s", __func__ , strerror(
errno ) );
    }
    else
      printf("Attached to %s\n",  __PROBE_QUEUE );
  }
  return( ( void* )( & mqd ) );

}

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

Re: [Xenomai-help] Posix skin and message queues operation mode misunderstanding

[Philippe Gerum]

juanba romance wrote:
> Hello all i am trying to use a POSIX message queue object to interface a
> couple of application modules and  i am fully confused.
> 
> The execution environment is configured with a fully operational 
> xenomai-2.4.2 /linux 2.6.24-2 framework
> 
> First at all a test program is written/assembled using the librt stuff
> without any xenomai component in order to check the "standard POSIX"
> behavior
> The program works in two modes via input switches
> the "r" mode creates a POSIX queue and attach a notifier through the
> method SIGEV_THREAD, the main sleeps a while before close the created object
> for each callback the notifier empties the queue dumping the values and
> register again the callback symbol up to main flow is timed out .
> the "w" mode tries to push a pattern data set into the created queue in
> burst mode
> So one pid empties the queue and the other apply data. The linux domain
> version using the librt works at expected.
> 
> The weird thing is when we compile the stuff using the xeno-config
> switches so we build xenomai domain message queues..
> Such stuff doesn't provide any feedback to the notifier symbol of the
> reader PID ??
> The writer PID however doesn't provide any error relative to queue
> open/send system calls
> 
> It seems that i am misunderstanding something really basic when these
> objects are applied on the Xenomai domain.
> 
> Could somebody provide me any hint ?

your mq_notify() call actually fails, because SIGEV_THREAD is not currently
supported. SIGEV_SIGNAL is. A bug in the interface library prevents you from
getting the right call status.

--- src/skins/posix/mq.c	(revision 3549)
+++ src/skins/posix/mq.c	(working copy)
@@ -191,6 +191,14 @@

 int __wrap_mq_notify(mqd_t mqdes, const struct sigevent *notification)
 {
-	return -XENOMAI_SKINCALL2(__pse51_muxid,
-				  __pse51_mq_notify, mqdes, notification);
+	int err;
+
+	err = XENOMAI_SKINCALL2(__pse51_muxid,
+				__pse51_mq_notify, mqdes, notification);
+	if (err) {
+		errno = -err;
+		return -1;
+	}
+
+	return 0;
 }

-- 
Philippe.

Re: [Xenomai-help] Posix skin and message queues operation mode misunderstanding

[juanba romance]

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

On Sat, Mar 8, 2008 at 12:44 PM, Philippe Gerum <rpm@xenomai.org> wrote:

> your mq_notify() call actually fails, because SIGEV_THREAD is not
> currently
> supported. SIGEV_SIGNAL is. A bug in the interface library prevents you
> from
> getting the right call status.
>
> --- src/skins/posix/mq.c        (revision 3549)
> +++ src/skins/posix/mq.c        (working copy)
> @@ -191,6 +191,14 @@
>
>  int __wrap_mq_notify(mqd_t mqdes, const struct sigevent *notification)
>  {
> -       return -XENOMAI_SKINCALL2(__pse51_muxid,
> -                                 __pse51_mq_notify, mqdes, notification);
> +       int err;
> +
> +       err = XENOMAI_SKINCALL2(__pse51_muxid,
> +                               __pse51_mq_notify, mqdes, notification);
> +       if (err) {
> +               errno = -err;
> +               return -1;
> +       }
> +
> +       return 0;
>  }
>
> --
> Philippe.
>

I got it, uhmm i will applied above patch on our current tree to prevent
future misunderstandings
Anyway i will check the probe program using the SIGEV_SIGNAL feedback method
instead of

Thanks a lot Philippe
cheers

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

Re: [Xenomai-help] Posix skin and message queues operation mode misunderstanding

[juanba romance]

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

On Sat, Mar 8, 2008 at 7:04 PM, Philippe Gerum <rpm@xenomai.org> wrote:

> Yes it does. Maybe contributing the needed support for SIGEV_THREAD to the
> Xenomai library would spare you way more invasive changes to your code
> base.
> After all, honoring SIGEV_THREAD seems to me a matter of running a server
> thread
> in the background to poll for notifications, which is what we do in a
> number of
> occasions for other skins. Additionally, we don't actually care if this
> support
> is only available to userland programs, and not to kernel-based modules.
>
> Philippe.
>

I see, well, imho its a performance issue for our concerns, we developed our
APIs, in general terms, based on threads dispatching instead of signal
delivering due to the "historic" limited bandwidth in the signal mechanisms
under Unix/Linux..whatever.

Right now, we dont have a clear idea about it..  so we move on in a first
approach with software re-usage issues in mind cause we have already passed
a validation proccess. Anyway the required modifications seems not to be too
hard(right now), so before deep inside we will check our application
prototypes following your current capabilities..

Best regards.

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

Re: [Xenomai-help] Posix skin and message queues operation mode misunderstanding

[Gilles Chanteperdrix]

juanba romance wrote:
 > On Sat, Mar 8, 2008 at 7:04 PM, Philippe Gerum <rpm@xenomai.org> wrote:
 > 
 > > Yes it does. Maybe contributing the needed support for SIGEV_THREAD to the
 > > Xenomai library would spare you way more invasive changes to your code
 > > base.
 > > After all, honoring SIGEV_THREAD seems to me a matter of running a server
 > > thread
 > > in the background to poll for notifications, which is what we do in a
 > > number of
 > > occasions for other skins. Additionally, we don't actually care if this
 > > support
 > > is only available to userland programs, and not to kernel-based modules.
 > >
 > > Philippe.
 > >
 > 
 > I see, well, imho its a performance issue for our concerns, we developed our
 > APIs, in general terms, based on threads dispatching instead of signal
 > delivering due to the "historic" limited bandwidth in the signal mechanisms
 > under Unix/Linux..whatever.
 > 
 > Right now, we dont have a clear idea about it..  so we move on in a first
 > approach with software re-usage issues in mind cause we have already passed
 > a validation proccess. Anyway the required modifications seems not to be too
 > hard(right now), so before deep inside we will check our application
 > prototypes following your current capabilities..
 > 
 > Best regards.

Xenomai posix skin signals cause the target thread to switch to
secondary mode, so, it may not be a good idea to use them.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Posix skin and message queues operation mode misunderstanding

[juanba romance]

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

>
> Xenomai posix skin signals cause the target thread to switch to
>
secondary mode, so, it may not be a good idea to use them.
>                                            Gilles Chanteperdrix.


I understand that since the first callback instruction up to call the
mq_receive xenomai system call, isn't it ?

We were thinking to customize the real-time operative passing some
parameters only under a controlled application state. So at same time we
need to connect the real time operative to any "secondary" object, maybe
other approaches are preferred..

If the mq_receive returns to the primary domain we can assume the hole along
the configuration process timing.

Best Regards

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

Re: [Xenomai-help] Posix skin and message queues operation mode misunderstanding

[Gilles Chanteperdrix]

juanba romance wrote:
 > >
 > > Xenomai posix skin signals cause the target thread to switch to
 > >
 > secondary mode, so, it may not be a good idea to use them.
 > >                                            Gilles Chanteperdrix.
 > 
 > 
 > I understand that since the first callback instruction up to call the
 > mq_receive xenomai system call, isn't it ?

Yes, it is.

 > 
 > We were thinking to customize the real-time operative passing some
 > parameters only under a controlled application state. So at same time we
 > need to connect the real time operative to any "secondary" object, maybe
 > other approaches are preferred..
 > 
 > If the mq_receive returns to the primary domain we can assume the hole along
 > the configuration process timing.
 > 

I do not understand what you mean. But from my point of view, using
message queues notification through SIGEV_THREAD or SIGEV_SIGNAL will
never be nearly as fast as a server thread calling mq_receive in a
loop.

-- 


					    Gilles Chanteperdrix.