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
QNX4->QNX6: select()/_select_receive()
Re: QNX4->QNX6: select()/_select_receive()
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
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
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.
Re: QNX4->QNX6: select()/_select_receive()
David Gibbs <dagibbs@qnx.com> wrote:
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.
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();
}
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
I've got some problems with the definition of this term. I suspect,Are you writing a resource manager or not?
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.
So we cannot use the standard select() structure for this?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.
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();
}
Just to give an impression, what we actually do: we're about to portUse ionotify() directly allows you to multiplex, asking for
pulse notification. (select() uses a special signal.)
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
Re: QNX4->QNX6: select()/_select_receive()
Karsten.Hoffmann@mbs-software.de wrote:
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.)
Either:
resmgr_attach()
select_attach()
while(1)
{
dispatch_block()
dispatch_handler()
}
Or:
name_attach()
ionotify()
ionotify()
while(1)
{
/* optional timeout if busy */
MsgReceive()
dowork()
}
toolkit?
-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Ok...I should have said are you writing an application that does aDavid 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.
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.)
Not in a single-threaded application. (As far as I can tell.)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?
Nope.Let me see, if I got this right:
name_attach();
select_attach(my_select_handler);
Either:
resmgr_attach()
select_attach()
while(1)
{
dispatch_block()
dispatch_handler()
}
Or:
name_attach()
ionotify()
ionotify()
while(1)
{
/* optional timeout if busy */
MsgReceive()
dowork()
}
That's quite a port. Have you grabbed and read through the migrationJust 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)
toolkit?
Welcome.Thanks for your help,
-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Re: QNX4->QNX6: select()/_select_receive()
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
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