Thanks for your reply! I had originally thought I could do exactly as you
say but what stopped me was a sentence in the Krten “Getting Started” book,
Chapter 5, pg 343:
“In most cases we could have just used MsgRead(), but in the case where this
message is part of a “combine message,” resmgr_msgread() performs the
appropriate “magic” for us.”
I was worried about missing out on the “magic”…I don’t want to break
combine messages in the event that the C lib decides to use one. But in the
implementation you dug up I see no evidence of “magic”.
Perhaps I can get away with MsgRead() directly…that would be a fine
[Mr Krten: Hope you don’t mind that I cc’ed you… I’m curious as to whether
the magic you mentioned is non-existent in the implementation Kevin showed
or just invisible to us mortals… Would you consider it safe to just
blindly use MsgRead()?]
“Kevin Stallard” <email@example.com.> wrote in message
Because io_writes are a MsgSend() from a client I belive all you really
is the rcvid in order to finish reading data from the client. MsgRead()
what you would use with the recvid.
I just verified this by checking the source code for resmgr_msgread() (on
cvs.qnx.com) …it is a wrapper for MsgRead(). The only thing you would
have to do is also track the number of bytes you’ve already read from the
client performing the write().
int resmgr_msgread(resmgr_context_t *ctp, void *msg, int nbytes, int
return MsgRead(ctp->rcvid, msg, nbytes, ctp->offset + offset);
Hope this helps
“Adam Kropelin” <> firstname.lastname@example.org> > wrote in message
news:an9grh$b9g$> email@example.com> …
Thanks for your reply. You’ve given me some ideas to think about.
I’ve been unable to access QNX’s developer site for the last several
I’m not sure if the problem is on their end or mine. After IE spins for
few minutes I get what appears to be an error from our local proxy
I looked in my local copy of the docs and read the article I think you
referencing. Unfortunately, the section on blocking the client is a
too simplistic > > Blocking reads are easy to handle: save the recvid
and do the MsgReply yourself at some later time. The client stays
until you reply. Easy.
But writes, on the other hand… The reason I would be blocking the
in that case is that I don’t have room in my internal buffer to hold
much data he’s trying to write. (If I have no internal buffer at all,
same problem exists, except that I’m waiting for the hardware to become
available.) I want to block him until I have room for the data (wither
the hw or my buffer). Saving the recvid alone is not enough for that
You need the whole ctp in order to call resmgr_msgread() when you’re
ready to retrieve his data. Without the ctp, I don’t know what to do.
As for O_NONBLOCK, opening with that flag generally implies that you’ll
the call (EAGAIN) if it would block, not that you would enable some
double-buffering scheme. It would be possible to change the semantics
as you suggest but I’m not sure that’s the POSIXy way to do it.
Letting the hardware flow-control the system makes a lot of sense, but
then I have the same problem. I need to block the writer. I can’t tie up
server thread sitting in io_write() because I’ll potentially deadlock
driver. (Think what happens when write() gets called from several
each of which blocks a server thread, and soon there are no threads left
even for read()s.) So I have to return from io_write() while leaving the
client blocked and having not read his data yet. Same problem.
Thanks again for your help. Any further ideas?
“John Roul” <> firstname.lastname@example.org> > wrote in message
news:an4rvi$4gh$> email@example.com> …
I’m by far not an expert in writing QNX device drivers and am in fact
to learn some of these things as well, I came across an article in the
l#ReturnComesFromResMgr , specifically the section “Leaving the client
blocked, replying later” which actually describes blocking and
The literature here does imply you can handle the ctp and save and
the reply ID anyway you want and it seems the driver is the one that
in fact to block or unblock. I’m not totally clear on your intentions
it sounds like your trying to make this driver be as efficient as
whether you need to really buffer any of the data depends on the rest
your system’s architecture > > Maybe you could give the user of the
the option of opening with O_NONBLOCK and never block, always implying
double buffer and worker thread to dispatch it. If they didn’t ask to
blocked, just allow the hardware to flow-control the caller of the
service; if it takes a while to return when blocking so be it, as long
other parts of the system can handle the back log. Anyways, I think
lets you do what your asking no matter which way you go.
Hopefully I understood correctly and didn’t miss the point. I’m sure
are others out there that can offer more insight, just my 1/2 cents