QNX4->QNX6: select()/_select_receive()

[Guest]

I'm actually trying to port a QNX4 programme with the following
structure:


forever
{
if(busy_work_to_do)
time_val = 0;
else
time_val = 10s;

select(...,time_val)
/*
** Standard select handling
*/

if(timer_expired && busy_work_to_do)
DoWork();
}



pid_t _select_receive(pid_t proxy)
{
Receive();
/*
** ... as from the docs
*/
}


I'm not sure how to port this to QNX6.
Can I combine a select() and a message_attach(), such like:


name_attach()

message_attach(,my_message_handler)


forever
{
if(busy_work_to_do)
time_val = 0;
else
time_val = 10s;

select(...,time_val)
/*
** Standard select handling
*/

if(timer_expired && busy_work_to_do)
DoWork();
}


What do I need the message type 'range' in 'message_attach()' for?
I couldn't find any place, where I could use a message type for
sending, or is it the first word in the message itself?

Thanks for any hints!

:Karsten.


--
__ __ ____ ____
| \/ | __ ) ___| Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |\/| | _ \___ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |_) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|_| |_|____/____/ Mobile: +49-172-3812373 D-47809 Krefeld

[David Gibbs]

Karsten.Hoffmann@mbs-software.de wrote:

Are you writing a resource manager or not?

With resmgr, use select_attach() to multiplex select() with MsgReceive().

With normal program, use ionotify().

select() basically does an ionotify() then waits to be unblocked,
then does some polling.

Use ionotify() directly allows you to multiplex, asking for
pulse notification. (select() uses a special signal.)

-David

I'm actually trying to port a QNX4 programme with the following
structure:

forever
{
if(busy_work_to_do)
time_val = 0;
else
time_val = 10s;

select(...,time_val)
/*
** Standard select handling
*/

if(timer_expired && busy_work_to_do)
DoWork();
}

pid_t _select_receive(pid_t proxy)
{
Receive();
/*
** ... as from the docs
*/
}

I'm not sure how to port this to QNX6.
Can I combine a select() and a message_attach(), such like:

name_attach()

message_attach(,my_message_handler)

forever
{
if(busy_work_to_do)
time_val = 0;
else
time_val = 10s;

select(...,time_val)
/*
** Standard select handling
*/

if(timer_expired && busy_work_to_do)
DoWork();
}


What do I need the message type 'range' in 'message_attach()' for?
I couldn't find any place, where I could use a message type for
sending, or is it the first word in the message itself?

Thanks for any hints!

:Karsten.

--
__ __ ____ ____
| \/ | __ ) ___| Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |\/| | _ \___ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |_) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|_| |_|____/____/ Mobile: +49-172-3812373 D-47809 Krefeld

--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Guest]

David Gibbs <dagibbs@qnx.com> wrote:

Are you writing a resource manager or not?

I've got some problems with the definition of this term. I suspect,
that the most of our tasks are considered to be a 'resource manager',
since they start agents, that send back messages or proxies -- and
they contact other servers to retrieve information as well. Some use
Photon, some not.

With resmgr, use select_attach() to multiplex select() with MsgReceive().

With normal program, use ionotify().

select() basically does an ionotify() then waits to be unblocked,
then does some polling.

So we cannot use the standard select() structure for this?

Let me see, if I got this right:

name_attach();

select_attach(my_select_handler);

for(;;)
{
if(busy_work_to_do)
{
event.sigev_notify = SIGEV_UNBLOCK;
TimerTimeout(...,NTO_TIMEOUT_RECEIVE,...);
}
MsgReceive(...);
DoWork();
}

Use ionotify() directly allows you to multiplex, asking for
pulse notification. (select() uses a special signal.)

Just to give an impression, what we actually do: we're about to port
ca. 450 modules/applications from QNX4 to QNX6, using a large variety
of 'messaging architecture' representing out past 15 years of
developing under QNX -- some module even have their roots in
QNX2/QNX-Windows. Currently I'm dealing with #10 or so )


Thanks for your help,

:Karsten.

--
__ __ ____ ____
| \/ | __ ) ___| Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |\/| | _ \___ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |_) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|_| |_|____/____/ Mobile: +49-172-3812373 D-47809 Krefeld

[David Gibbs]

Karsten.Hoffmann@mbs-software.de wrote:

David Gibbs <dagibbs@qnx.com> wrote:

Are you writing a resource manager or not?


I've got some problems with the definition of this term. I suspect,
that the most of our tasks are considered to be a 'resource manager',
since they start agents, that send back messages or proxies -- and
they contact other servers to retrieve information as well. Some use
Photon, some not.

Ok...I should have said are you writing an application that does a
resmgr_attach(), and then either a resmgr_block(), resmgr_handler() or
dispatch_block() and dispatch_handler() for its main loop?

QNX6 Resource Manager maps to QNX4 IO Manager. Something that registers
a name, handles open, read, write messages, etc. (Except, how to write
one is far better documented with a far more useful supporting library.)

With resmgr, use select_attach() to multiplex select() with MsgReceive().

With normal program, use ionotify().

select() basically does an ionotify() then waits to be unblocked,
then does some polling.

So we cannot use the standard select() structure for this?

Not in a single-threaded application. (As far as I can tell.)

Let me see, if I got this right:

name_attach();

select_attach(my_select_handler);

Nope.

Either:

resmgr_attach()
select_attach()
while(1)
{
dispatch_block()
dispatch_handler()
}

Or:
name_attach()
ionotify()
ionotify()
while(1)
{
/* optional timeout if busy */
MsgReceive()
dowork()
}

Just to give an impression, what we actually do: we're about to port
ca. 450 modules/applications from QNX4 to QNX6, using a large variety
of 'messaging architecture' representing out past 15 years of
developing under QNX -- some module even have their roots in
QNX2/QNX-Windows. Currently I'm dealing with #10 or so )

That's quite a port. Have you grabbed and read through the migration
toolkit?

Thanks for your help,

Welcome.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Guest]

Just for the records:

I decided to go the following way, which seems to mean the least
efforts for our problem:

.
.
.
name_attach();

pthread_mutex_lock(&mutex);
StartReceiverThread();
.
.
for(;;)
{
pthread_mutex_unlock(&mutex);
select();
pthread_mutex_lock(&mutex);
.
. /* standard select() handling */
.
}


ReveiverThread()
{
pthread_mutex_lock(&mutex);

for(;;)
{
pthread_mutex_unlock(&mutex);
MsgReceive();
pthread_mutex_lock(&mutex);
}
}


Quite simple and almost compatible to the old
select()/_select_receive() structure )

Thanks for your help, David!

Best regards,

:Karsten.


--
__ __ ____ ____
| \/ | __ ) ___| Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |\/| | _ \___ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |_) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|_| |_|____/____/ Mobile: +49-172-3812373 D-47809 Krefeld