RFC: QNX4 vs. QNX6

[Kevin_Stallard1]

Thomas,
I guess I wouldn’t put MsgReceives() in separate threads. If I’m going to
put a MsgReceive() in some other thread than the main thread, then I’m going
to put it into a separate process.

My own personal preference when it comes to dealing with threads is to use
them only when I want to do some specific job, and then quit, or make them
block on a mutex or something. I guess I’ve adopted the philosophy that a
binary should have one receive and if it needs to start a thread to handle a
request, then so be it. The context switch time in QNX being so low, I
guess I lean towards creating a separate process if I come to a point where
I should be putting a MsgReceive() in a thread.

So in essence, the channel question comes from the way that I’ve approached
problems in the past, figuring (as sometimes my blinders get in the way)
that most people do this as well (all things considered).

Regards,
Kevin



<thomasf@qnx.com> wrote in message news:aenqmh$iu2$1@nntp.qnx.com…

Kevin Stallard <> kevin@ffflyingrobots.com> > wrote:

[ Comments snipped ]

I don’t like this notion that seems to be permiating that we should
just
use TCP/IP for all our stuff. I really dislikeTCPIP for embedded
systems.
It makes no sense to me to use it after having been spoiled with FLEET
on
QNX 4. I look at the S/R/R interface for QNX6 and I don’t understand
why
somethings where done. (Channels for example) So I guess my point is,
the
beauty of QNX was it making a network of QNX nodes into one virtual CPU.

I hate to drive this further off topic, but …

To clarify about channels …

With QNX6 you are now using real threads. While we could have gone
with the QNX4 approach of just wacking a message at a process, that
would have been rather limiting (Only a single message queue per
process, no clear way to define thread involvement with resources
for the purpose of priority inheritance etc). As a result the
communication channel had to be extracted/abstracted from the
process container. (just in the same way that QNX4 conveniently
tied them together to a pid (and nd), because you could only ever
have one).

So QNX4 you had:
node, pid, chid == pid so ignore the chid
Under QNX6 you have:
node, pid, chid

An on extensibility …

The QNX6 mechanism makes it possible in the future to have a pool
of threads which can service multiple channels rather than just one,
which in turn cuts down your overall resourcing. Not that we have
such a broadcast/multiple queue receive API in place right now, but
it is conceivable that you could. Under QNX4 it would have been
must more difficult.

[More comments snipped]

Thomas

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com > Core OS Technology Group
(613)-591-0931 > http://www.qnx.com/

[Kris_Warkentin1]

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:aenrh8$jb2$1@nntp.qnx.com…

Heh, I just told Kris how one can do a ditto outside of dev-con >
It won’t be perfect though.

No, you can’t “clone” a dev-con device, but you can have your
own res manager regist “/dev/con1” (with FLAG_BEFORE); So whoever
open("/dev/con1") your manager got the request, it then relay
the request to the “real” /dev/con1.

Then you use a buffer to remember (say last 8k) datas write to you,
and whoever “ditto” to /dev/con1 (which will open/devctl your manager),
you send back the buffer, and taking care the sharing.

The problem is strings write to a console may have ESC sequence, and
break a sequence could result garbige showing up on dittoer’s screen.

I was just snooping around in cvs. I didn’t realize that devc-con was an
x86 only device which means that any hackery to it would only get you your
x86 targets. Perhaps Xiaodan’s solution is the more flexible one because
then it at least has a chance of being portable to systems where the console
is on the serial port. Any solution we come up with would have to support
all of our targets. I don’t imagine that putting plumbing in every devc
driver would be very scalable so perhaps some sort of resmgr which sits on
top of a device cacheing its output would be the trick. As I observed
earlier, most of what people need can be obtained simply by being able to
read the console.

One use that I would personally put this to would be to keep a console
window open to see what’s happening in my photon session.

cheers,

Kris

[Kevin_Stallard1]

Hey Paul,

I didn’t mean to inferr that I didn’t like POSIX. It definatly makes the OS
more attractive, but more that I didn’t want the massive redundant and
parallel aspects of the OS to be watered down. Which I’m sure they
aren’t…just my own personal growing pains from moving from QNX4, and not
being able to do somethings I was used to.

Regards,
Kevin

“Paul D. Smith” <pausmith@nortelnetworks.com> wrote in message
news:p5adpscvcf.fsf@lemming.engeast.baynetworks.com…

Want to pipe up with a counterpoint.

We chose QNX exactly because of its slavish adherence to POSIX. If QNX
was not POSIX, we wouldn’t have looked twice at it.

I don’t mind wrappers or whathaveyou for people who feel POSIX makes
things too hard, but please don’t “water down” the POSIX compliance. To
us, that’s the #1 priority. QNX has already distinguished itself
with it’s POSIX compliance; some say that “oh it’s just another
POSIX-based RTOS”, but if you look into this (as I have) you’ll see that
most of the OSs out there say they’re POSIX, and some of those (like
Linux) legitimately want to be POSIX, but there are few or none that
are POSIX, at least enough to implement robust, reliable environments
without a slew of non-standard hacks. QNX does it.

We need TCPIP; our entire system is predicated on it.

Watcom was probably nice for Intel folks, but they have no solution
whatever for non-Intel platforms, so we don’t care about them. And we’d
much rather have (and I’m sure QSSL agrees) a single toolkit that works
on all the platforms.

So, in all these ways QNX is getting it exactly right, IMO. Keep it up!


My concern: I hope we don’t see the all-too-common “GUI mindset” take
over at QSSL. I’ve seen far too many companies making good, useful
development tools virtually ruin their products by deciding they must
have fancy GUI interfaces: invariably they spend 85% of their time
trying to get the GUI working, debugging it, supporting it, etc. and
meanwhile the infinitely more useful command line interfaces are left to
languish and wither.

GUI: just say no! >

–

---

Paul D. Smith <> pausmith@nortelnetworks.com> > HASMAT–HA Software Mthds &
Tools
“Please remain calm…I may be mad, but I am a professional.” --Mad
Scientist

---

These are my opinions—Nortel Networks takes no responsibility for
them.

[Kevin_Stallard1]

Robert,
Device drivers are fine, ones that support streams (serial ports, etc), but
using them as a server that provides some service, is requiring that I twist
the meaning of read and write some…I’m still trying to get used to it.
(dev_ctrl() isn’t all that attractive of an option sometimes).

Like I said, I’m still getting used to it…

Regards,
Kevin
“Robert Krten” <nospam88@parse.com> wrote in message
news:aenslj$b06$1@inn.qnx.com…

Kevin Stallard <> kevin@ffflyingrobots.com> > wrote:
[snip]

It makes no sense to me to use it after having been spoiled with FLEET
on
QNX 4. I look at the S/R/R interface for QNX6 and I don’t understand
why
somethings where done. (Channels for example) So I guess my point is,
the
beauty of QNX was it making a network of QNX nodes into one virtual CPU.

Channels were created because in QNX 4 communications was done on a
process ID to process ID basis; in QNX 6 you have threads, which are
ephemeral (misspelled $10 word), so you can’t just decide which thread
you want to talk to – you might want to have, for example, two pools
of threads that handle two different services, so hence the channel
was created to abstract that away…

I just finished writing a resource manager and there are some things
about
it that bug me. I’m not sure I can articulate them yet, but I will be
in a
the next few months as I play with it some more.

I’d be interested in hearing your articulations; to me a QNX 6 resmgr
is just that much simpler than a QNX 4 driver of the same functionality.

I don’t know if you want to call it syntax sugar, or what but, like Jim
said, QNX4 was easy and I’m finding road blocks and disapointments with
QNX6
(GDB for exmaple I really liked watcom’s debugger in comparson. It
seems
that GDB is a step back, not forward, the compile times with gcc are
also

I haven’t noticed. The printf() debugger is still the same under QNX 6
as it was under QNX 4 >

annoying). I was surprised when QNET was not offered from the start
with
Neutrino, it made me wonder if the IPC architecture had been watered
down
such that it wasn’t possible to do stuff like in the past.

I think it was just a timing thing. They wanted to get QNET done right,
so instead of releasing it over and over again, they delayed it…

Kris, in a post here you responded to Mario and asked “You left qnet
running
on your machine in the field?”

It currently has known security issues… and since it’s on top of IP,
it’s a lot more “visible” than FLEET was – consider the case of
a cablemodem (broadband) type of network, and you can see where having
your /net directory populated with the machine names of other QSSL
developers who live in your neighbourhood is, to say the least,
interesting >

I hope this was a sarcastic question or that I took it out of context.
If
it wasn’t and I didn’t then you clearly don’t understand why at least I
have
choosen to base my systems on QNX. It is exactly because I want to run
QNET
in the field. It is this idea that machines can be hooked together to
create a fault tolerant, redundant and parallel system without the
clunkyness of a technology that is at least 2 decades old. In QNX 4 I
was
able to debug over radio modems by using QNX’s native netowrking. Now I
have to install and configure TCIP./IP then PPP and all that garbage to
do
the same thing, and its slower and uses more bandwidth thats lame!
Qith
QNX4, could run my vehcile control system from any node. I know I still
can
with QNX6, but it’s not as easy. I’m finding road blocks with QNX6 and
they
surprise me when I come up against them. So far I’ve found ways around
them, but they initially strike me as uncecessary.

There’s nothing wrong with running QNET on a closed and secure
system; hopefully the security issues will be addressed Real Soon Now…

[snip]

QNX has to be distinct from the other Unix like OS’s, you can’t conform
and
expect to be noticed. There have to be things that give an aura of
being
superior in most if not all areas, then people have to be educated on
how
and why it is better so they understand. I like the idea that we can
compile other stuff on it and run it, but I don’t like the idea of
making it
just like linux or unix. It can’t be just another clone. The ideas
that
QNX expouses are good and benificial, they have to be kept and
highlighted.
Using tcpip for everything is lame game.

TCP/IP is routable; FLEET wasn’t. Once security gets put into TCP/IP,
imagine the benefits of being able to “cd /net/australia/some_machine”
and have it “just work” instead of the QNX 4 method where you would have
required a specialized tunnel…


Cheers,
-RK

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.

[Richard_Kramer]

One thing that we do frequently with QNX4 is dial a customer’s site
to perform some maintenance chore or another that may require several
hours. We may start processes on more than one console, then hang up.

Some time later we can dial back in and ditto those consoles to check
progress, respond to a prompt or whatever. Can that sort of thing be
done without ditto?

Richard

Kris Warkentin wrote:

Ultimately what is required to get the work done is to see exactly what
people want and how badly they want it. Since people quite often don’t
really know what they want, it’s better to look at what they need. That is,
“what problem are we trying to solve”?

At the top level the problem is, “Getting access to a remote machines
console”.

Questions that arise from that:

“Do you need write access or is read access sufficient?” Given that there
are other ways to execute processes on a remote machine, perhaps just being
able to read the console (especially if we were to cache a few pages) might
be enough.

“What level of security is expected?” Should it be safe to use over the
internet or strictly for internal use?

“What are the likely situations that this will be used for?” We have the
situation of the lab and the tech support. Are there others?

I’m sure there are others. I’m hoping that we can properly specify exactly
what the problem is, which will allow us to properly specify the solution.
We may find that parts of ditto will not be required because other
mechanisms exist. So far, most usage scenarios that I’ve seen come down to
“I want to see what is happening/has happened on the console” which is a
smaller problem to solve than the solution ditto provides. Perhaps a way to
start devc-con with a certain cache size and then an interface to retrieve
that information would be sufficient.

cheers,

Kris

[Adam_Mallory1]

<camz@passageway.com> wrote in message news:aeniaa$4af$1@inn.qnx.com…

I don’t think ANY of use really care if it was tied to x86 or not. It
provided
a useful function. As Mario points out it has uses where you used
Dev.ditto
to create a console for a system (embedded target) that might not have had
a real console at all. This is probably a scenario that is quite common
in
the “new world” that QNX6 exsits in. Not all non-x86 platforms have the
concept of a console. The concept of a console is very useful, and
appears
in many situations, both javascript and java virtual machines provide a
“console”. These are not related to the underlying hardware at all. The
concept of a “console” is 100% valid and useful.

I never said the ditto was useless, nor did I ever say it had no place. It
is useful (in some cases), and I do in fact use it (being a QNX4 user).
What I’m trying to illustrate here is that it’s not just a matter of “take
the QNX4 source and rebuild”. The concept of a console is very useful
indeed - it is a concept however, and there are non-trival issues with
making those concepts interoperate on multiple platforms.

So, don’t tie it to the x86/PC arcitechture where viewing the console is
nothing more than dumping some memory. Implement in a way that is
dependant
on the OS architechture, not the hardware. io-char process with some
devctl()'s for accessing it, perhaps some helper functions that
communicate
with io-char that allow any character-based devc-* driver to access to
make
itself “ditto-able”.

That’s obvious - I think the fact that we’d require it to work on multiple
platforms suggests we don’t tie the functionality to the underlying
architecture of the machine.

Don’t treat us like idiots. We are asking for the functionality because
it
was useful to us.

Whoa - I never suggested anything of the sort. There is no end to the
number of people that ask for “function x” for pidin, just because sin did
it, regardless of it relevance in Neutrino. In addition, Xtang made a
“tongue in cheek” remard about ‘sin vc’ - so for the sake of others reading,
I just mentioned that some features where not relevant.

I respect other peoples opinions, and I expect the same in return. (note: I
don’t always agree).

Sure the instrumented kernel can give a good view into
a running system, and the various interactions. There was functionality
and
information that sin provided that the instrumented kernel would not be
able
to provide, at least not easily. What IRQ’s are in use? Sure, some IRQ’s
that a driver should use are specified on the cmdline, most however are
auto-detected. The instrumented kernel won’t tell me that. What files
are
open? Who has them open? I need to run chkfsys on a filesystem, I need
to
know what processes to kick that have files open for write on that
partition
before I can proceed.

Actually you can find out what IRQ’s are in use based on the events emitted;
further you could even find out which IRQ events are causing scheduling
events so another process to can run. Open files are the same idea (events
emitted from Proc) - if you prefer the way sin did it, that’s fine.

So, we ask for the functionality because it was useful to us, not simply
because “QNX4 had it”.

I was simply saying that if the same functionaly existed in different form,
I think we should concentrate on getting new and/or improved features
instead of duplicating what is already there.

We aren’t but there wasn’t much functionality in sin that wasn’t useful,
so
asking for “all the functionality of QNX4 sin” is just shorthand for the
list
of information it provided without having to list them all individually.
How you provide that information to us (ie. how it should be done) isn’t
relevent. Just provide the means for us to get the information. We don’t
have that right now. We’d like it.

So what you’re saying here is that you didn’t quite mean what you typed

In any case, if the ability to extract the information you need isn’t
present - I agree we should get it to you in some form.

–
Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

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>

[Bill_Caroselli_Q-TPS]

All of my servers have many times more “control” messages than read and
write messages. If fact, I would say 80% control and only 15% IO. (The
other 5% is reserved for future definition.)

The only real IO I do to/from a server is in my data base server. And
there, I don’t want anything that looks like stream IO. I want record based
IO.

“Kevin Stallard” <kevin@ffflyingrobots.com> wrote in message
news:aenvot$dh1$1@inn.qnx.com…

Robert,
Device drivers are fine, ones that support streams (serial ports, etc),
but
using them as a server that provides some service, is requiring that I
twist
the meaning of read and write some…I’m still trying to get used to it.
(dev_ctrl() isn’t all that attractive of an option sometimes).

Like I said, I’m still getting used to it…

Regards,
Kevin

[Adam_Mallory1]

Yes, but if the information already exists in a “different from QNX4” form,
why expend the resources on duplication.

In anycase, I think we all agree on the basics, and Kris has his list. Now
we just have to see who’s been naughty or nice

–
Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

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>

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:aenlqb$6r2$1@inn.qnx.com…

“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:aenama$5ka$> 1@nntp.qnx.com> …

IMHO, limiting ones thinking to “this is the way it should be done”, is
just
that… limiting.

Hi Adam,

I think that Kris’s original request was, “What are some of the QNX4
features that we need to add to QNX6?”

[Bill_Caroselli_Q-TPS]

“Mario Charest” postmaster@l127.0.0.1 wrote in message
news:aenu7h$cft$1@inn.qnx.com…

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:aenkho$5nq$> 1@inn.qnx.com> …

Several of my programs are constantly writing status information to a
text
console that no one ever looks at just so that information is available
IF
someone wants to look at it. I’ve always been disappointed that Dev.com
only had 10 consoles. I could have used 50. I would have each program
have
it’s own status console.

You can, just start another Dev.con and you can create another set of
10 consoles, which can only be view via ditto though > > I’ve seen system
with 30 consoles.

Actually I’ve used Dev.ditto like this. I didn’t know you could do it with

Dev.con too.

[Xiaodan_Tang1]

Richard Kramer <rrkramer@kramer-smilko.com> wrote:

One thing that we do frequently with QNX4 is dial a customer’s site
to perform some maintenance chore or another that may require several
hours. We may start processes on more than one console, then hang up.

Some time later we can dial back in and ditto those consoles to check
progress, respond to a prompt or whatever. Can that sort of thing be
done without ditto?

Well, there is “on -t”,

on -t con1 app1 2>&1 >/tmp/log.con1 &
on -t con2 app2 2>&1 >/tmp/log.con2 &
…

But again, I still vote for ditto

-xtang

Richard

Kris Warkentin wrote:

Ultimately what is required to get the work done is to see exactly what
people want and how badly they want it. Since people quite often don’t
really know what they want, it’s better to look at what they need. That is,
“what problem are we trying to solve”?

At the top level the problem is, “Getting access to a remote machines
console”.

Questions that arise from that:

“Do you need write access or is read access sufficient?” Given that there
are other ways to execute processes on a remote machine, perhaps just being
able to read the console (especially if we were to cache a few pages) might
be enough.

“What level of security is expected?” Should it be safe to use over the
internet or strictly for internal use?

“What are the likely situations that this will be used for?” We have the
situation of the lab and the tech support. Are there others?

I’m sure there are others. I’m hoping that we can properly specify exactly
what the problem is, which will allow us to properly specify the solution.
We may find that parts of ditto will not be required because other
mechanisms exist. So far, most usage scenarios that I’ve seen come down to
“I want to see what is happening/has happened on the console” which is a
smaller problem to solve than the solution ditto provides. Perhaps a way to
start devc-con with a certain cache size and then an interface to retrieve
that information would be sufficient.

cheers,

Kris

[Xiaodan_Tang1]

Robert Krten <nospam88@parse.com> wrote:

Kevin Stallard <> kevin@ffflyingrobots.com> > wrote:

Kris, in a post here you responded to Mario and asked “You left qnet running
on your machine in the field?”

It currently has known security issues… and since it’s on top of IP,
it’s a lot more “visible” than FLEET was – consider the case of
a cablemodem (broadband) type of network, and you can see where having
your /net directory populated with the machine names of other QSSL
developers who live in your neighbourhood is, to say the least, interesting >

Well, QNET actually on top of IP or Ether (default) now.
So by default, only ppl on your local lan could attack you.

Up to date cable modems will block broadcast packet, seeing
your neighber’s machine pop up in “Network Neighbourhood” causing
too much scream.

And finally, why do you think I wrote that fs-ac thing?

-xtang

[Bill_Caroselli_Q-TPS]

Despite all the insistence that “just because sin had it doesn’t mean it’s
necessary”, so far, no one mentioned “sin ve”, which is also a very useful
diagnostic aid.

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:aedho6$q6o$1@nntp.qnx.com…

Attention QNX users.

I am compiling a wish-list for utilities development over the next 6
months
to a year. I’m mostly looking for things that existed in QNX4 but don’t
in
QNX6 but I’m also taking general utils feature requests.

So, if there are any utilities you wish you had or enhanced functionality
to
existing utilities, now is the time to let me know so I can try to get
them
on the road map.

cheers,

Kris

[Kris_Warkentin1]

Actually, I got some email from the hardware guys who want sin ver
‘yesterday’. Apparently the ‘stuff’ is in place to get the version out of a
running app now, it’s just a matter of accessing it. It’s on my list.

Kris

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:aeo37h$g16$1@inn.qnx.com…

Despite all the insistence that “just because sin had it doesn’t mean it’s
necessary”, so far, no one mentioned “sin ve”, which is also a very useful
diagnostic aid.

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:aedho6$q6o$> 1@nntp.qnx.com> …
Attention QNX users.

I am compiling a wish-list for utilities development over the next 6
months
to a year. I’m mostly looking for things that existed in QNX4 but don’t
in
QNX6 but I’m also taking general utils feature requests.

So, if there are any utilities you wish you had or enhanced
functionality
to
existing utilities, now is the time to let me know so I can try to get
them
on the road map.

cheers,

Kris
\

[Robert_Krten1]

Kris Warkentin <kewarken@qnx.com> wrote:

Actually, I got some email from the hardware guys who want sin ver
‘yesterday’. Apparently the ‘stuff’ is in place to get the version out of a
running app now, it’s just a matter of accessing it. It’s on my list.

use -i ?

Kris

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:aeo37h$g16$> 1@inn.qnx.com> …
Despite all the insistence that “just because sin had it doesn’t mean it’s
necessary”, so far, no one mentioned “sin ve”, which is also a very useful
diagnostic aid.

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:aedho6$q6o$> 1@nntp.qnx.com> …
Attention QNX users.

I am compiling a wish-list for utilities development over the next 6
months
to a year. I’m mostly looking for things that existed in QNX4 but don’t
in
QNX6 but I’m also taking general utils feature requests.

So, if there are any utilities you wish you had or enhanced
functionality
to
existing utilities, now is the time to let me know so I can try to get
them
on the road map.

cheers,

Kris

\

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

[Kevin_Stallard1]

Even with a thread pool, you have one receive() that passes work off to
other threads that then reply. Having a receive in a thread (the main
thread) and then worker threads I don’t see how that would be limiting.
Lots easier to figure out who to send to…

Kevin
“Rennie Allen” <rallen@csical.com> wrote in message
news:3D0F52CA.50704@csical.com…

Kevin Stallard wrote:

I guess I’ve adopted the philosophy that a
binary should have one receive and if it needs to start a thread to
handle a
request, then so be it. The context switch time in QNX being so low, I
guess I lean towards creating a separate process if I come to a point
where
I should be putting a MsgReceive() in a thread.

In all seriousness, this is a limiting philosophy. There is nothing wrong
with preferring a seperate process over multiple threads with differing
responsibilities; but there is also a lot “correct” about a dispatch
interface with a thread pool. Denying yourself this model, is IMO, very
limiting, but entirely within your rights; however, I, for one, want the
OS to support multiple models of application construction.

Rennie

[Xiaodan_Tang1]

Kevin Stallard <kevin@ffflyingrobots.com> wrote:

Even with a thread pool, you have one receive() that passes work off to
other threads that then reply. Having a receive in a thread (the main
thread) and then worker threads I don’t see how that would be limiting.
Lots easier to figure out who to send to…

That is where you are wrong.

Every thread in the pool doing receive(), only one of them will
unblock if a message arrived. “Which one” is not important,
they are all same “worker threads”.

Now if you have “worker1 threads” and “worker2 threads”, they
do different job, how’s that going to happen? That’s where
“Channel” comming in, “worker1 threads” receive() on channel 1,
and “workder2 threads” receive() on channel 2.

-xtang

[Kevin_Stallard1]

Right, but then the whole chid thing seems to me pointless in that model. I
was reading Thomas as saying that you would have a seperate receive in each
thread and each thread would have its own chid.

What I was trying to say earlier was that I’m not going to create a new
channel for each new thread and block on that channel. I"m going to have
one point to which all clients will ‘MsgSend’. I understood Thomas to say
that the chid gives us the ability to have each thread block on its own
channel, and I haven’t found a reason how this would be usefull to me.
Maybe this would be usefull at some point, but I haven’t seen how this would
help me solve any problems yet. I figure it’s a lot easier for a client to
find a server if he didn’t have to also figure out which thread he wanted to
talk to (which chid I should say).

Kevin




“Rennie Allen” <rallen@csical.com> wrote in message
news:3D0F7A60.7010905@csical.com…

Kevin Stallard wrote:
Even with a thread pool, you have one receive() that passes work off to
other threads that then reply.

In the model I am interested in, each thread calls receive, but only one
thread calls receive at a time.

Having a receive in a thread (the main
thread) and then worker threads I don’t see how that would be limiting.
Lots easier to figure out who to send to…

The whole point is, who cares what thread does the work (all threads
travel through the same code) ? The process is capable of performing a
set of services, threads only enable it to do what it does
simultaneously (if you are on an SMP box).

Rennie

[Kevin_Stallard1]

Hey xtang, how’s it going?

Yeah, I get it, but this where I differ in philosophy. I am having a hard
time visualizing a situation where I’m going to have a process represented
by more than one chid. If I am going to have more than one chid, then I’m
going to move the functionality around that chid into a seperate process.
(At least this is how I look at it currently).

Kevin

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:aeoml0$8si$1@nntp.qnx.com…

Kevin Stallard <> kevin@ffflyingrobots.com> > wrote:
Even with a thread pool, you have one receive() that passes work off to
other threads that then reply. Having a receive in a thread (the main
thread) and then worker threads I don’t see how that would be limiting.
Lots easier to figure out who to send to…

That is where you are wrong.

Every thread in the pool doing receive(), only one of them will
unblock if a message arrived. “Which one” is not important,
they are all same “worker threads”.

Now if you have “worker1 threads” and “worker2 threads”, they
do different job, how’s that going to happen? That’s where
“Channel” comming in, “worker1 threads” receive() on channel 1,
and “workder2 threads” receive() on channel 2.

-xtang

[system]

Kevin Stallard <kevin@ffflyingrobots.com> wrote:

Device drivers are fine, ones that support streams (serial ports, etc), but
using them as a server that provides some service, is requiring that I twist
the meaning of read and write some…I’m still trying to get used to it.
(dev_ctrl() isn’t all that attractive of an option sometimes).

Kevin, I had this same concern when initially using QNX6 after coming from
the QNX4 world things seemed pretty simple with the whole skeleton like this:

name_attach();
for(; {
pid = Receive(0, … );
switch() {
case:
case:
…
}
Reply( pid, … );
}

At first the QNX6 resmgr certainly looks like massive overkill, not to
mention that it doesn’t intuitively appear to even allow for the switch()
type of processing. In reality, there IS a way to do this, complete
with the entire switch()/case processing. There is another way too that
allows you to implement this without the switch()/case and using the
call-back method for each “case”. You can even mix both of these if you
like. Neither of these require that you try to use the read/write streams
at all, the default handlers take care of that for you, effectively making
them behave like /dev/null.

This actually makes the QNX6 model much more powerful for more or less
the same “price”. You can start off with the QNX4 “traditional” method
of using private messages, and transition to the resmgr method of using
devctl(), you can even support both simultaneously.

I will admit this was a BIG barrier for me. It was a huge mental leap
from the QNX4 S/R/R “simple” model to the (seemingly) more complex QNX6
resmgr model. I have to thank Chris McKillop for walking me gently
through the transition on IRC.

If you want some help in how to do the more traditional switch()/case
thing in QNX6, let me know and I can dig up my test code to help you
through it as well.

Cheers,
Camz.

[system]

Kris Warkentin <kewarken@qnx.com> wrote:

public network. I absolutely agree that QNET (as FLEET was before) is a
good solution for networking if the system is isolated.

Interestingly enough if you look at something like Beowolf clustering for
Linux you will find that the model that you have to add the beowolf “layer”
to achieve is more or less the QNET / FLEET native model. That just blows
my mind. Linux has to work hard to acheive functionality that has natively
been available in QNX since QNX2.

The proper way to think of a QNET/FLEET network is that of an SMP machine
with “loosely coupled” CPUs. A multi-processor motherboard is not that
different and is just “tightly coupled” CPUs. The slick thing with QNX6
is that you can have BOTH. That is incredibly powerful and so much more
efficient when you take into account the fact that QNX achieves it without
any additional network layers.

Cheers,
Camz.