My last DMA-intensive multithreaded wonder had to withhold replying to the
clients until some undefined time later (when hardware actually provides the
data, which happened asynchronously and often out of order due to the fact
that hardware had hundreds of ‘ports’, its own CPU and memory). So explicit
MsgReply() when data actually was available made good sense.
They have their use. But not if I can reasonably help it. Amen.
“David Bacon” <dbacon@qnx.com> wrote in message
news:1122987974778.dB@inn.qnx.com…
For anyone still following this rather dull and rambling
thread, I just want to correct something I wrote earlier:Happy I may be to interface with Msg* routines at the resmgr
level, but I don’t actually seem to do it! I looked through
my latest multi-threaded, DMA-intensive wonder, and it turns
out I only made two references to Msg* routines (MsgInfo()
and MsgError()), and even the code sequence that contains
those calls is preceded by a warning expressing this
programmer’s surprise that it should be executed at all
(I think iofunc_unblock_default() is already supposed to
have taken care of what that code does).The reason is that the resmgr_, iofunc_, dispatch_, and
thread_pool_ functions in QNX’s libc, combined with the
fact that the I/O “callbacks” only need to return data to
their callers in order to effect appropriate MsgReply()s,
comprise a higher and more convenient level than the raw
Msg* routines do. So I use 'em.dB
David Bacon wrote ~ 1 Aug 2005 16:44:57 GMT:
For the sake of their own convenience and risk mitigation,
customers should be encouraged to use POSIX APIs rather than
QNX native message passing where possible. Look at it from
a risk-conscious customer’s point of view (and here we’re
usually talking about the manager, not his brilliant
programmer, who never sees risks):Suppose you were trying to choose between Linux and QNX, and
were leaning in favour of QNX because of its architectural
advantages, but for some reason thought you needed to use the
native message-passing API in QNX even at the applications
level to get any kind of decent performance, convenience, or
whatever. You would run immediately to Linux rather than
paint yourself into a corner like that. But if you know you
can write portable POSIX code and get good performance out of
it on QNX, your investment is protected in case other factors
compel a switch to, say, BSD, Linux, or Solaris.And I really am talking only about the applications level.
I am very happy to interface with the Msg* routines at the
resource manager level, and if Bill Caroselli wants to write
a library that gives his clients (applications programmers)
a portable interface because he supports that library on a
variety of systems, that’s great. But his library will be
a piece of infrastructure: it is systems software, not
applications software.Applications programmers will always do best to use the most
portable, high-level interface that is practicable for their
needs.dB
Rennie Allen wrote ~ Mon, 01 Aug 2005 16:13:07 -0700:
Igor Kovalenko wrote:Ok, I think I see what you’re saying now, but again you use an
irrelevant
example to make your point. We were discussing writing applications,
not
system libraries.The issue was that David Bacon said that he agreed that it is
inappropriate that application developers use MsgSend directly (this is
a blanket statement). I then pointed out an example where using
MsgSend
directly (as an application developer) is quite likely appropriate.
How
more relevant could it possibly be (actual customer, who is an actual
application developer, who - for some reason - required the ability to
replace the timer_* set of functions) ?Rennie