In the brief amount of testing that i’ve done, it seems that the first
channel id created by any process (and any channel id created at any
time, as long as there are none others extant at the time) is always 1.
If this is true, this makes a considerable simplification possible in
porting an existing app from QNX4… just replace:
Send(pid, …) with (conceptually)
MsgSend( ConnectAttach(0, pid, 1, _NTO_SIDE_CHANNEL, 0), … )
Then this horrible migration-process-manager hack (even if you’re
looking for something quick and dirty) seems not even worth
considering. Of course, this glosses over a few details but it means
that the QNX6 Send() implementation doesn’t need any extra info beyond
what it always had (the pid).
But it all depends upon being able to rely upon that first/only
channel ID always being 1. Does anyone think this way of approaching
this particular migration problem has any merit?
But it all depends upon being able to rely upon that first/only
channel ID always being 1. Does anyone think this way of approaching
this particular migration problem has any merit?
While it has merit, I would be hesitant to do that, since you’re banking on
internal behaviour, which could change in a different revision or might not
apply to the process you’re sending to.
While the method may work for you, the person taking over your code will
curse your name if/when that behaviour changes, since a message send could
be the primitive that much of your system is based upon.
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
For better or worse, we have done exactly this and we aren’t losing any
sleep over it.
The only ‘extra’ thing we do is on the server side we check that the channel
id we are allocated by ChannelCreate() is actually 1. If it isn’t we print a
very obvious error message and exit. This way if the behviour of QNX changes
in the future then at least we will know why things are failing (rather than
experiencing the kind of mysterious failure that Adam warns about).
Of course this only works for servers that we write ourselves. I certainly
wouldn’t recommend this approach for dealing with ‘3rd party’ servers.
Rob Rutherford
“Craig Duncan” <craig@duncan.nycap.rr.com> wrote in message
news:ufwuqk7ve8.fsf@pop.nycap.rr.com…
In the brief amount of testing that i’ve done, it seems that the first
channel id created by any process (and any channel id created at any
time, as long as there are none others extant at the time) is always 1.
If this is true, this makes a considerable simplification possible in
porting an existing app from QNX4… just replace:
Send(pid, …) with (conceptually)
MsgSend( ConnectAttach(0, pid, 1, _NTO_SIDE_CHANNEL, 0), … )
Then this horrible migration-process-manager hack (even if you’re
looking for something quick and dirty) seems not even worth
considering. Of course, this glosses over a few details but it means
that the QNX6 Send() implementation doesn’t need any extra info beyond
what it always had (the pid).
But it all depends upon being able to rely upon that first/only
channel ID always being 1. Does anyone think this way of approaching
this particular migration problem has any merit?
Craig Duncan <craig@duncan.nycap.rr.com> wrote:
In the brief amount of testing that i’ve done, it seems that the first
channel id created by any process (and any channel id created at any
time, as long as there are none others extant at the time) is always 1.
If this is true, this makes a considerable simplification possible in
porting an existing app from QNX4… just replace:
Send(pid, …) with (conceptually)
MsgSend( ConnectAttach(0, pid, 1, _NTO_SIDE_CHANNEL, 0), … )
Then this horrible migration-process-manager hack (even if you’re
looking for something quick and dirty) seems not even worth
considering. Of course, this glosses over a few details but it means
that the QNX6 Send() implementation doesn’t need any extra info beyond
what it always had (the pid).
But it all depends upon being able to rely upon that first/only
channel ID always being 1. Does anyone think this way of approaching
this particular migration problem has any merit?
FWIW, the QNX4 to 6 migration library depends on this “behaviour”
as well. That is, it depends on the first channel being chid 1.
And, I’m pretty sure the mig-process-manager isn’t used for the
Send(), it in fact turns into a MsgSend()ÿsomething like what yours
does.
The mig-process-manager does things like proxy emulation using messages
and qnx_name_locate()/qnx_name_attach() emulation.
Also, the mig stuff is intended for use in the early stages of porting,
not really for a final target, think of it as primarily intended as a
stepping-stone along the way to a full port.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.