QNX resource manager and pulse question...

QNX USERS QNX6 - Applications
1

Hi all,

I am not sure whether this is the right forum to ask my question. If not can you please redirect me to the appropriate forum ?

I have written a resource manager (My first attempt to write) to handle requests from clients… MY requirement is, if the resource manager bootsup or dies for whatever reason, it needs to somehow signal the client process that it is up or dead so that the client can take some action. I read through the documentation and it talks about signals, pulse, dumpers, etc…etc… It is very confusing …

I was thinking somehow the server resource manager sends a pulse when it boots up and when it dies so that if there is any client process waiting on this process, it would get the appropriate signal .
But in the code, I am stuck as to how to handle this. I couldn’t find much source code examples for this. I would appreciate any kind of guidance for me to move forward with this requirement.

I am including my code snippet for anybody interested…

Thanks in advance for your time.

//Resource manager…
//////////////////////////////////////////////////////////////////////////
int main(int argc, char *argv)
{
/ declare variables we’ll be using */
resmgr_attr_t resmgr_attr;
dispatch_t *dpp;
dispatch_context_t *ctp;
int id;
struct _pulse buf;

/* initialize dispatch interface */
if((dpp = dispatch_create()) == NULL) {
    fprintf(stderr,
            "%s: Unable to allocate dispatch handle.\n",
            argv[0]);
    return EXIT_FAILURE;
}

/* initialize resource manager attributes */
memset(&resmgr_attr, 0, sizeof(resmgr_attr));
resmgr_attr.nparts_max = 1;
resmgr_attr.msg_max_size = 2048;

/* initialize functions for handling messages */
iofunc_func_init(_RESMGR_CONNECT_NFUNCS, &connect_funcs,
                 _RESMGR_IO_NFUNCS, &io_funcs);

connect_funcs.open = io_open;
io_funcs.read = io_read;
io_funcs.write = io_write;
io_funcs.devctl = io_devctl;

/* initialize attribute structure used by the device */
iofunc_attr_init(&attr, S_IFNAM | 0666, 0, 0);

/* attach our device name */
id = resmgr_attach(
        dpp,                         /* dispatch handle        */
        &resmgr_attr,              /* resource manager attrs */
        FPGA_DEVICE_NAME,  /* device name            */
        _FTYPE_ANY,             /* open type              */
        0,                            /* flags                  */
        &connect_funcs,         /* connect routines       */
        &io_funcs,               /* I/O routines           */
        &attr);                     /* handle                 */
if(id == -1) {
    fprintf(stderr, "%s: Unable to attach name.\n", argv[0]);
    return EXIT_FAILURE;
}

/* allocate a context structure */
ctp = dispatch_context_alloc(dpp);


/* start the resource manager message loop */
while(1) {


    if((ctp = dispatch_block(ctp)) == NULL) {
        fprintf(stderr, "block error\n");
        return EXIT_FAILURE;
    }
  //How do I send the pulse to the client  or should it be handled somewhere else in this program  ??
    dispatch_handler(ctp);
}


return EXIT_SUCCESS;

}

2

If your resource manager dies for whatever reason, it is dead and can no longer signal a process.

It is however possible for the client process to be informed. If you are not in a hurry, the client can simple examine the error return code it will receive when trying to communicate with the resource manager. If you are in a hurry, there are a number of routes you might take. Since you said “whatever reason” you can’t count on some termination code executing and communicating to the client in some manner. On the other hand, with a third party process you could handle this. One way might be as follows.

Third party process creates two threads. One waits for messages from the client, and the other starts the resource manager and waits for it to die.

The client finds the third party process and sends a message indicating that it is interested in finding out when the resource manager dies.

When the resource manager dies, the third party raises a signal on the client.

This is just one way to handle this situation and may not be appropriate for what you want to do.