Using socket() in qnx rtp

As read in the book “getting started with qnx neutrino”, the c library
performs the standard calls into a message passing manner. Effectively how
much overhead this “wrapper” adds to the standard c library?

And wat about network operations? Is the bsd socket api a wrapper to some
message passing mechanism? Are there any way to bypass this wrapper api and
use directly the message passing (I don’t need to produce portable code)?
It is a safe thing to do or it’s discouraged?

I’m trying to develop a strange network application. This application will
use message passing for comunicating with other clients, so using only
message passing would be a cleaner desing (we could use se same functions
like MsgWrite and so on) but have also to communicate with some standard tcp
protocols. Developing code to do the inverse thing
(socket api → message passing) may be as reinventing the wheel.

Any comment is appreciated

Using message passing directly is not discouraged, although may not be
best idea either. I’ve seen lot of cases when people thought ‘hey that
is too complex, let’s nuke it all and use raw messages’. Raw messages
are simple for very simple cases, but as your application grows you
quickly hit a point when you need to establish some formal protocol with
headers, handshakes, etc, etc. Designing that protocol to be reliable in
all situations can be often a non-trivial task.

What I mean is you should look at the resource manager framework, which
encapsulates raw messages into standard file-desctirptor based I/O. It
also provides automatic thread-pool management for multithreaded
servers. If you go that way you could then easily mix your own I/O with
sockets using select(). And the client code would be portable.

if you decide to go with raw messages you can do that too. The
ionotify() call allows you to receive pulses with notification about
socket I/O into MsgReceive() call, so you can wait for your own messages
and socket data in single entry point.

  • igor

wavexx@apexmail.com wrote:

As read in the book “getting started with qnx neutrino”, the c library
performs the standard calls into a message passing manner. Effectively how
much overhead this “wrapper” adds to the standard c library?

And wat about network operations? Is the bsd socket api a wrapper to some
message passing mechanism? Are there any way to bypass this wrapper api and
use directly the message passing (I don’t need to produce portable code)?
It is a safe thing to do or it’s discouraged?

I’m trying to develop a strange network application. This application will
use message passing for comunicating with other clients, so using only
message passing would be a cleaner desing (we could use se same functions
like MsgWrite and so on) but have also to communicate with some standard tcp
protocols. Developing code to do the inverse thing
(socket api → message passing) may be as reinventing the wheel.

Any comment is appreciated

wavexx@apexmail.com wrote:

As read in the book “getting started with qnx neutrino”, the c library
performs the standard calls into a message passing manner. Effectively how
much overhead this “wrapper” adds to the standard c library?

I would say “near zero” in most case:). libc is posted on cvs.qnx.com, you
could check it out yourself.

And wat about network operations? Is the bsd socket api a wrapper to some
message passing mechanism? Are there any way to bypass this wrapper api and
use directly the message passing (I don’t need to produce portable code)?
It is a safe thing to do or it’s discouraged?

Yes, socket api is a wrapper of message, you probably could figure
it out by take a look of “sys/sockmsg.h” file. I don’t see “use directly
message passing” could buy you too much, except save a function call
and return (inline a function).

-xtang

I’m trying to develop a strange network application. This application will
use message passing for comunicating with other clients, so using only
message passing would be a cleaner desing (we could use se same functions
like MsgWrite and so on) but have also to communicate with some standard tcp
protocols. Developing code to do the inverse thing
(socket api → message passing) may be as reinventing the wheel.

Any comment is appreciated