Hello,
does anybody know what Neutrino makes with multiple ConnectAttach() calls
from the SAME process to the SAME Channel ID? Does the returned connection
ID vary? Does Neutrino keep track of the number of ConnectAttach()-calls in
this configuration? What happens when I call ConnectDetach() while having
called ConnectAttach() multiple times before? Does it close ALL connections
or just one at a time?
Thanks.
Nnamdi
Connection ids are just like file descriptors. You can open the same file
multiple times (unless the server prohibits that), so you can have multiple
connections. They will be different. Yes, they keep track of those things.
Closing a connection will only close one.
– igor
“Nnamdi Kohn” <nnamdi.kohn@web.de> wrote in message
news:c59477$6ao$1@inn.qnx.com…
Hello,
does anybody know what Neutrino makes with multiple ConnectAttach() calls
from the SAME process to the SAME Channel ID? Does the returned connection
ID vary? Does Neutrino keep track of the number of ConnectAttach()-calls
in
this configuration? What happens when I call ConnectDetach() while having
called ConnectAttach() multiple times before? Does it close ALL
connections
or just one at a time?Thanks.
Nnamdi
Thanks for the info, Igor.
What about the execution / management times? Does a MsgSend() consume more
processing time when there are a lot of connection Ids valid for the same
resource?
Nnamdi
“Igor Kovalenko” <kovalenko@attbi.com> schrieb im Newsbeitrag
news:c59m4a$jnj$1@inn.qnx.com…
Connection ids are just like file descriptors. You can open the same file
multiple times (unless the server prohibits that), so you can have
multiple
connections. They will be different. Yes, they keep track of those things.
Closing a connection will only close one.– igor
“Nnamdi Kohn” <> nnamdi.kohn@web.de> > wrote in message
news:c59477$6ao$> 1@inn.qnx.com> …
Hello,does anybody know what Neutrino makes with multiple ConnectAttach()
calls
from the SAME process to the SAME Channel ID? Does the returned
connection
ID vary? Does Neutrino keep track of the number of ConnectAttach()-calls
in
this configuration? What happens when I call ConnectDetach() while
having
called ConnectAttach() multiple times before? Does it close ALL
connections
or just one at a time?Thanks.
Nnamdi
\
Nnamdi Kohn <nnamdi.kohn@web.de> wrote:
Thanks for the info, Igor.
What about the execution / management times? Does a MsgSend() consume more
processing time when there are a lot of connection Ids valid for the same
resource?
No.
But, depending on when/how this occurs it may still flag a bug. If
something is unintentionally attaching, using, then forgetting to
detach and just attaching again, this can start to consume more
system resources.
There are other cases, as mentioned by others, where multiple attaches
to the same channel can be intentional and is normal behaviour.
-David
–
David Gibbs
dagibbs@qnx.com
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:c5eee3$id0$1@inn.qnx.com…
Nnamdi Kohn <> nnamdi.kohn@web.de> > wrote:
Thanks for the info, Igor.What about the execution / management times? Does a MsgSend() consume
more
processing time when there are a lot of connection Ids valid for the
same
resource?No.
But, depending on when/how this occurs it may still flag a bug. If
something is unintentionally attaching, using, then forgetting to
detach and just attaching again, this can start to consume more
system resources.
I would say ‘it depends’…
Things really start to get slow to the point of rendering the entire system
foobar, when you have too many senders shoving something into a single
channel at very fast rate. Which I suspect very well might be a case when
one has lot of connections opened to the same channel. This is due to a
certain design deficiency in the kernel that won’t be addressed until after
6.3…
Using more channels to do the same work helps a lot in such cases. That’s of
course only easy when data being sent can be logically split between
different channels.
There are other cases, as mentioned by others, where multiple attaches
to the same channel can be intentional and is normal behaviour.
Yeah, but beware of the wolf.
– igor