Is there any function available to determine the number of opend channels
within a process (even if the channels are flagged with _NTO_SIDE_CHANNEL)?
I want to cover the funtionality of connecting to a server process into a
library reusing the channel of the calling process if there is one already
opend.
cheers, Peter
Peter Weber <pw@dolphin.de> wrote:
Is there any function available to determine the number of opend channels
within a process (even if the channels are flagged with _NTO_SIDE_CHANNEL)?
I want to cover the funtionality of connecting to a server process into a
library reusing the channel of the calling process if there is one already
opend.
_NTO_SIDE_CHANNEL is a flag to ConnectAttach(). This gives you a
connection id.
There isn’t an easy way to determine the number of open connections,
and I’m not sure how the number would help you – the calling process
to your library might have connections open to various servers, including
the one you want to talk to, but also to others.
I see a couple possibilites for the re-use – pass the coid back to
the calling process after an “open” or “connect” type library call,
and then use it when passed in again. Or, use a “global” to your
library variable to represent the client’s connection to your server,
initialize it with ConnectAttach() first time they talk to your server,
then re-use that library global every time thereafter.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Thanks David.
but…
Is there any function available to determine the number of opend
channels
within a process (even if the channels are flagged with
_NTO_SIDE_CHANNEL)?
I want to cover the funtionality of connecting to a server process into
a
library reusing the channel of the calling process if there is one
already
opend._NTO_SIDE_CHANNEL is a flag to ConnectAttach(). This gives you a
connection id.
Yes, I know that, but I want to say that I see no fd based function/solution
to detect a channel
using coid’s from the normal or from the extra fd space (side_channel). I
was looking for a function like
‘channel_id = GetChannelIDFromConnectionID(coid)’ or something like
channel_id = GetFirstChannel(void);
The problem is not the coid. The problem is to attach a connection to an
existing channel.
The structure in my software is:
A client process maintains a connection to a server and waits for pulses.
In the server I use MsgDeliverEvent() for notification. The client transfers
the
channel ID receiving pulses on, via the connect() function to the server.
If the client goes RECV-blocked on a channel, waiting for pulses AND other
messages,
this channel must be the same channel previously ‘registered’ via connect()
to the server
to receive the pulses. I’m correct?
My client lib use name_open() in the library which returns ‘only’ a coid as
an fd mapped from
the normal fd space( no side channel). Sending a message to the server this
coid
is ‘enough’, but to receive pulses, I have to use a channel id. I’m correct?
In other words, I MUST create an additional channel and I also have to use
name_open()
to find the server which results in an extra channel. In 99% of cases an
application has
only one channel and may be multiple connections. If there is only one
‘common’ MsgReceivev(),
I must attach all connections to this channel.
Do you understand my problem?
There isn’t an easy way to determine the number of open connections,
and I’m not sure how the number would help you – the calling process
to your library might have connections open to various servers, including
the one you want to talk to, but also to others.
Not connections! I’m looking for channels to attach my connection to
this channel.
I see a couple possibilites for the re-use – pass the coid back to
the calling process after an “open” or “connect” type library call,
and then use it when passed in again. Or, use a “global” to your
library variable to represent the client’s connection to your server,
initialize it with ConnectAttach() first time they talk to your server,
then re-use that library global every time thereafter.
Using globals in a library makes my nose bleeding This is not an option
for me.
cheers, Peter
Peter Weber <pw@dolphin.de> wrote:
Thanks David.
but…>
Is there any function available to determine the number of opend
channels
within a process (even if the channels are flagged with
_NTO_SIDE_CHANNEL)?
I want to cover the funtionality of connecting to a server process into
a
library reusing the channel of the calling process if there is one
already
opend._NTO_SIDE_CHANNEL is a flag to ConnectAttach(). This gives you a
connection id.
Yes, I know that, but I want to say that I see no fd based function/solution
to detect a channel
using coid’s from the normal or from the extra fd space (side_channel). I
was looking for a function like
‘channel_id = GetChannelIDFromConnectionID(coid)’ or something like
channel_id = GetFirstChannel(void);
ConnectServerInfo(coid, …)
The problem is not the coid. The problem is to attach a connection to an
existing channel.
The structure in my software is:
A client process maintains a connection to a server and waits for pulses.
In the server I use MsgDeliverEvent() for notification. The client transfers
the
channel ID receiving pulses on, via the connect() function to the server.
If the client goes RECV-blocked on a channel, waiting for pulses AND other
messages,
this channel must be the same channel previously ‘registered’ via connect()
to the server
to receive the pulses. I’m correct?
Not really.
Your client have to creat a channel (yes, client create channel), and
then your client ConnectAttach() to this channel (yes, connect to
itself) to get a coid.
Then your client prepare an “Pulse Event”, with that coid, and the
pulse code/value you wish to receive.
Then your client connect to server (name_open()), send a message
with that event to server (something like, if condition A happened,
deliver me THIS event).
The server should “MsgReply()” immediatly, but store rcvid & event
from that message.
The client could do it’s own job, but it have to do a MsgReceive()/
MsgReceivePulse() on the channel it create in step 1.
The server, once detect “condition A happened”, MsgDelivere(rcvid,
event) back to client to inform client.
-xtang
My client lib use name_open() in the library which returns ‘only’ a coid as
an fd mapped from
the normal fd space( no side channel). Sending a message to the server this
coid
is ‘enough’, but to receive pulses, I have to use a channel id. I’m correct?
In other words, I MUST create an additional channel and I also have to use
name_open()
to find the server which results in an extra channel. In 99% of cases an
application has
only one channel and may be multiple connections. If there is only one
‘common’ MsgReceivev(),
I must attach all connections to this channel.
Do you understand my problem?There isn’t an easy way to determine the number of open connections,
and I’m not sure how the number would help you – the calling process
to your library might have connections open to various servers, including
the one you want to talk to, but also to others.Not connections! I’m looking for channels to attach my connection to
this channel.
I see a couple possibilites for the re-use – pass the coid back to
the calling process after an “open” or “connect” type library call,
and then use it when passed in again. Or, use a “global” to your
library variable to represent the client’s connection to your server,
initialize it with ConnectAttach() first time they talk to your server,
then re-use that library global every time thereafter.Using globals in a library makes my nose bleeding >
for me.
cheers, Peter
I’m sorry Xiaodan, but the function ConnectServerInfo() returns a coid not a
channel_id.
To explain it another way.
My application is working fine! There is no problem with it except:
the shared channel ID to use a MsgReceivev() later in the client.
In the client library I have:
cid = ChannelCreate(0),
coid = ConnectAttach(0, 0, cid, …);
msg_coid = name_open(“rubber_duck_server”, 0);
talk_to_server_using_MsgSendv(msg_coid); // up to here no
problem!
…
// then preparing the event using
SIGEV_PULSE_INIT(&event, coid, prio, _PULSE_CODE_MINAVAIL,
my_ulong_msg_code);
MsgSendv(msg_coid, &event,…); // works perfect, no problem.
// in the server
Reply(rcvid, WAS_GOOD…)
//storing rcvid and event and keep it until event occurs, then
MsgDeliverEvent(rcvid, &event); // works perfect, no problem
// But now back in the client !!!
// my process is a single thread with only one common MsgReceivev()
// and I MUST receive all messgages and pulses on a central single point.
while(boring) {
MsgReceivev(which_channel_I_should_use_to_get_the_pulse_AND_other_mess
ages_the_client_may_expect_from_other_connections ;
}
using cid from above I have to ‘export this cid’ out of the API and every
time the API
is called I get one channel more. And - I need an additional thread
to get the pulses/messages on the newly created cid.
What I would like to get is:
- If there is any channel already created by the client process,
use it by ConnectAttach to this channel,
if not, create one. This way I can re-use the channels and stay
RECV-blocked on one point.
That is what I asked for 
puahhhhh
thanx and cheers, Peter
“Xiaodan Tang” <xtang@qnx.com> schrieb im Newsbeitrag
news:ah6j87$eui$1@nntp.qnx.com…
Peter Weber <> pw@dolphin.de> > wrote:
Thanks David.
but…>
Is there any function available to determine the number of opend
channels
within a process (even if the channels are flagged with
_NTO_SIDE_CHANNEL)?
I want to cover the funtionality of connecting to a server process
into
a
library reusing the channel of the calling process if there is one
already
opend._NTO_SIDE_CHANNEL is a flag to ConnectAttach(). This gives you a
connection id.
Yes, I know that, but I want to say that I see no fd based
function/solution
to detect a channel
using coid’s from the normal or from the extra fd space (side_channel).
I
was looking for a function like
‘channel_id = GetChannelIDFromConnectionID(coid)’ or something like
channel_id = GetFirstChannel(void);ConnectServerInfo(coid, …)
Nope, sorry.The problem is not the coid. The problem is to attach a connection to an
existing channel.
The structure in my software is:
A client process maintains a connection to a server and waits for
pulses.
In the server I use MsgDeliverEvent() for notification. The client
transfers
the
channel ID receiving pulses on, via the connect() function to the
server.
If the client goes RECV-blocked on a channel, waiting for pulses AND
other
messages,
this channel must be the same channel previously ‘registered’ via
connect()
to the server
to receive the pulses. I’m correct?Not really.
Your client have to creat a channel (yes, client create channel), and
then your client ConnectAttach() to this channel (yes, connect to
itself) to get a coid.Then your client prepare an “Pulse Event”, with that coid, and the
pulse code/value you wish to receive.Then your client connect to server (name_open()), send a message
with that event to server (something like, if condition A happened,
deliver me THIS event).The server should “MsgReply()” immediatly, but store rcvid & event
from that message.The client could do it’s own job, but it have to do a MsgReceive()/
MsgReceivePulse() on the channel it create in step 1.The server, once detect “condition A happened”, MsgDelivere(rcvid,
event) back to client to inform client.-xtang
My client lib use name_open() in the library which returns ‘only’ a coid
as
an fd mapped from
the normal fd space( no side channel). Sending a message to the server
this
coid
is ‘enough’, but to receive pulses, I have to use a channel id. I’m
correct?
In other words, I MUST create an additional channel and I also have to
use
name_open()
to find the server which results in an extra channel. In 99% of cases an
application has
only one channel and may be multiple connections. If there is only one
‘common’ MsgReceivev(),
I must attach all connections to this channel.
Do you understand my problem?There isn’t an easy way to determine the number of open connections,
and I’m not sure how the number would help you – the calling process
to your library might have connections open to various servers,
including
the one you want to talk to, but also to others.Not connections! I’m looking for channels to attach my connection to
this channel.
I see a couple possibilites for the re-use – pass the coid back to
the calling process after an “open” or “connect” type library call,
and then use it when passed in again. Or, use a “global” to your
library variable to represent the client’s connection to your server,
initialize it with ConnectAttach() first time they talk to your server,
then re-use that library global every time thereafter.Using globals in a library makes my nose bleeding >
option
for me.
cheers, Peter
Peter Weber <pw@dolphin.de> wrote:
I’m sorry Xiaodan, but the function ConnectServerInfo() returns a coid not a
channel_id.
ConnectServerInfo() take a “pid” and a “coid” (fd), fill up your
“struct _server_info”, and the info->chid is the channel id that
the “coid” (of process pid) connect to.
To explain it another way.
My application is working fine! There is no problem with it except:
the shared channel ID to use a MsgReceivev() later in the client.In the client library I have:
cid = ChannelCreate(0),
coid = ConnectAttach(0, 0, cid, …);
msg_coid = name_open(“rubber_duck_server”, 0);
talk_to_server_using_MsgSendv(msg_coid); // up to here no
problem!
…
// then preparing the event using
SIGEV_PULSE_INIT(&event, coid, prio, _PULSE_CODE_MINAVAIL,
my_ulong_msg_code);
MsgSendv(msg_coid, &event,…); // works perfect, no problem.// in the server
Reply(rcvid, WAS_GOOD…)
//storing rcvid and event and keep it until event occurs, then
MsgDeliverEvent(rcvid, &event); // works perfect, no problem// But now back in the client !!!
// my process is a single thread with only one common MsgReceivev()
// and I MUST receive all messgages and pulses on a central single point.while(boring) {
MsgReceivev(which_channel_I_should_use_to_get_the_pulse_AND_other_mess
ages_the_client_may_expect_from_other_connections >
}using cid from above I have to ‘export this cid’ out of the API and every
time the API
is called I get one channel more. And - I need an additional thread
to get the pulses/messages on the newly created cid.
What I would like to get is:
- If there is any channel already created by the client process,
use it by ConnectAttach to this channel,
if not, create one. This way I can re-use the channels and stay
RECV-blocked on one point.
I don’t quite understand your library, but, typically you do:
SYSCBP *client_init() {
mysystem_cbp->chid = ChannelCreate();
mysystem_cbp->coid = ConnectAttach(mysystem_cbp->chid);
return (SYSCBP *)mysystem_cbp;
};
client_arm_server(SYSCBP *sys_cbp, …)
{
if (sys_cbp == 0) {
fprintf(stderr, “You MUST call client_init() first\n”);
errno = EINVAL;
return -1;
}
/* Init the pulse, MsgSend() to server … */
return 0;
}
client_block(SYSCBP *sys_cbp, …)
{
int rcvid = MsgReceive(sys_cbp->chid, …);
…
}
And a real client will using your API like:
int main()
{
SYSCBP *scbp = client_init();
client_arm_server(scbp, …)
client_block(scbp, …)
…
}
That is what typically how your handle a “pre-set
info” library API, of cause, you will add “client_destroy()”
to clean up things… Using “static int chid” in
library also could do same thing, but I saw you
against using global valuable. You can also make
the SYSCBP opaque, so client who using your lib
don’t even need to know what’s in SYSCBP. (Think
ouf DIR * returned by opendir()).
Remember, you are writing Library, so you are not
suppose to have power what “client” (who use your
library) will do. Think of a client doing:
int main()
{
int client_chid1 = ChannelCreate(0);
int client_chid2 = ChannelCreate(0);
call into your library.
}
How are you going to decided which chid to wait on?
-xtang
That is what I asked for >
thanx and cheers, Peter“Xiaodan Tang” <> xtang@qnx.com> > schrieb im Newsbeitrag
news:ah6j87$eui$> 1@nntp.qnx.com> …
Peter Weber <> pw@dolphin.de> > wrote:
Thanks David.
but…>
Is there any function available to determine the number of opend
channels
within a process (even if the channels are flagged with
_NTO_SIDE_CHANNEL)?
I want to cover the funtionality of connecting to a server process
into
a
library reusing the channel of the calling process if there is one
already
opend._NTO_SIDE_CHANNEL is a flag to ConnectAttach(). This gives you a
connection id.
Yes, I know that, but I want to say that I see no fd based
function/solution
to detect a channel
using coid’s from the normal or from the extra fd space (side_channel).
I
was looking for a function like
‘channel_id = GetChannelIDFromConnectionID(coid)’ or something like
channel_id = GetFirstChannel(void);ConnectServerInfo(coid, …)
Nope, sorry.The problem is not the coid. The problem is to attach a connection to an
existing channel.
The structure in my software is:
A client process maintains a connection to a server and waits for
pulses.
In the server I use MsgDeliverEvent() for notification. The client
transfers
the
channel ID receiving pulses on, via the connect() function to the
server.
If the client goes RECV-blocked on a channel, waiting for pulses AND
other
messages,
this channel must be the same channel previously ‘registered’ via
connect()
to the server
to receive the pulses. I’m correct?Not really.
Your client have to creat a channel (yes, client create channel), and
then your client ConnectAttach() to this channel (yes, connect to
itself) to get a coid.Then your client prepare an “Pulse Event”, with that coid, and the
pulse code/value you wish to receive.Then your client connect to server (name_open()), send a message
with that event to server (something like, if condition A happened,
deliver me THIS event).The server should “MsgReply()” immediatly, but store rcvid & event
from that message.The client could do it’s own job, but it have to do a MsgReceive()/
MsgReceivePulse() on the channel it create in step 1.The server, once detect “condition A happened”, MsgDelivere(rcvid,
event) back to client to inform client.-xtang
My client lib use name_open() in the library which returns ‘only’ a coid
as
an fd mapped from
the normal fd space( no side channel). Sending a message to the server
this
coid
is ‘enough’, but to receive pulses, I have to use a channel id. I’m
correct?
In other words, I MUST create an additional channel and I also have to
use
name_open()
to find the server which results in an extra channel. In 99% of cases an
application has
only one channel and may be multiple connections. If there is only one
‘common’ MsgReceivev(),
I must attach all connections to this channel.
Do you understand my problem?There isn’t an easy way to determine the number of open connections,
and I’m not sure how the number would help you – the calling process
to your library might have connections open to various servers,
including
the one you want to talk to, but also to others.Not connections! I’m looking for channels to attach my connection to
this channel.
I see a couple possibilites for the re-use – pass the coid back to
the calling process after an “open” or “connect” type library call,
and then use it when passed in again. Or, use a “global” to your
library variable to represent the client’s connection to your server,
initialize it with ConnectAttach() first time they talk to your server,
then re-use that library global every time thereafter.Using globals in a library makes my nose bleeding >
option
for me.
cheers, Peter
Thanks very much Xiaodan,
I agree that the client can open multiple channel and in the API I will have
no idea about
which channel to use. The reason for reuse of the channel in this case is,
the applications ported from
Q4 to NTO are designed to have a single point for blocking using
_select_receive().
We use exactly the same structure as you as a client handle, but we use
_select_receive() from
Q4 in the clients to use a central blocking point. Changes in this design
would result
in a complete recoding of all client processes.
Now I will try an aproach with the info->chid information.
Thank you again Xiaodan.
I’m sorry Xiaodan, but the function ConnectServerInfo() returns a coid
not a
channel_id.ConnectServerInfo() take a “pid” and a “coid” (fd), fill up your
“struct _server_info”, and the info->chid is the channel id that
the “coid” (of process pid) connect to.
Yeahhh…that was the thing I was looking for >
This is not in the docs. Only nd, pid and cred are described but I will take
a look into the header files now (and in the future;-).
http://www.qnx.com/developer/docs/qnx_6.1_docs/neutrino/lib_ref/c/connectser
verinfo.html
To explain it another way.
My application is working fine! There is no problem with it except:
the shared channel ID to use a MsgReceivev() later in the client.In the client library I have:
cid = ChannelCreate(0),
coid = ConnectAttach(0, 0, cid, …);
msg_coid = name_open(“rubber_duck_server”, 0);
talk_to_server_using_MsgSendv(msg_coid); // up to here no
problem!
…
// then preparing the event using
SIGEV_PULSE_INIT(&event, coid, prio, _PULSE_CODE_MINAVAIL,
my_ulong_msg_code);
MsgSendv(msg_coid, &event,…); // works perfect, no problem.// in the server
Reply(rcvid, WAS_GOOD…)
//storing rcvid and event and keep it until event occurs, then
MsgDeliverEvent(rcvid, &event); // works perfect, no problem// But now back in the client !!!
// my process is a single thread with only one common MsgReceivev()
// and I MUST receive all messgages and pulses on a central single
point.while(boring) {
MsgReceivev(which_channel_I_should_use_to_get_the_pulse_AND_other_mess
ages_the_client_may_expect_from_other_connections >
}using cid from above I have to ‘export this cid’ out of the API and
every
time the API
is called I get one channel more. And - I need an additional thread
to get the pulses/messages on the newly created cid.
What I would like to get is:
- If there is any channel already created by the client process,
use it by ConnectAttach to this channel,
if not, create one. This way I can re-use the channels and stay
RECV-blocked on one point.I don’t quite understand your library, but, typically you do:
SYSCBP *client_init() {
mysystem_cbp->chid = ChannelCreate();
mysystem_cbp->coid = ConnectAttach(mysystem_cbp->chid);
return (SYSCBP *)mysystem_cbp;
};client_arm_server(SYSCBP *sys_cbp, …)
{
if (sys_cbp == 0) {
fprintf(stderr, “You MUST call client_init() first\n”);
errno = EINVAL;
return -1;
}/* Init the pulse, MsgSend() to server … */
return 0;
}client_block(SYSCBP *sys_cbp, …)
{
int rcvid = MsgReceive(sys_cbp->chid, …);
This is the(our) problem----------------^
we don’t have this info in our client…or better… we expect more and
other messages from other channels too.
}
And a real client will using your API like:
int main()
{
SYSCBP *scbp = client_init();client_arm_server(scbp, …)
Up to here, thats exactly what we do but we can’t use the scbp for blocking!
client_block(scbp, …)…
}That is what typically how your handle a “pre-set
info” library API, of cause, you will add “client_destroy()”
to clean up things… Using “static int chid” in
library also could do same thing, but I saw you
against using global valuable. You can also make
the SYSCBP opaque, so client who using your lib
don’t even need to know what’s in SYSCBP. (Think
ouf DIR * returned by opendir()).
Yes Xiaodan, but it’s not neccessary to make it opaque.
The API is “open” and we could use the real structure.
problem is more difficult see above.
Remember, you are writing Library, so you are not
suppose to have power what “client” (who use your
library) will do. Think of a client doing:int main()
{
int client_chid1 = ChannelCreate(0);
int client_chid2 = ChannelCreate(0);call into your library.
}How are you going to decided which chid to wait on?
Yes - I agree. The reason was the reuse of the code
designed using _select_receive() from Q4. In Q4 we could use select()
to get messages and watching for fd’s becoming ready the same time.
The goooood old QNX4 did a Receivemx(0,…) and was open for the rest of the
world
see above.
-xtang
That is what I asked for >
thanx and cheers, Peter
- snip -
Thanks again Xiaodan, I will try a new aproach by using the info->chid
member.
cheers, Peter
Peter Weber <pw@dolphin.de> wrote:
Thanks very much Xiaodan,
I agree that the client can open multiple channel and in the API I will have
no idea about
which channel to use. The reason for reuse of the channel in this case is,
the applications ported from
Q4 to NTO are designed to have a single point for blocking using
_select_receive().
We use exactly the same structure as you as a client handle, but we use
_select_receive() from
Q4 in the clients to use a central blocking point. Changes in this design
would result
in a complete recoding of all client processes.
Now I will try an aproach with the info->chid information.
Ah, now I see where you heading to, the Old Good _select_receive()
So you want to select() and MsgReceive() at sametime…
Good thing we post library source on web, so you could know exactly
how “select()” works under NTO. Take a look here:
http://cvs/cgi-bin/product-cvsweb.cgi/lib/
xopen/select.c
qnx/select_event.c
qnx/select_block.c
In a short, “select.c” prepare a sigevent (a SIGSELECT signal event),
and call _select_event() with this “event”, and a block funciton
“_select_block()” (in select_block.c)
_select_event() simply fire the event cross fd (coid), and then
block into _select_block().
_select_block() basically go into sigtimedwait() to wait that SIGSELECT
comming in…
So here is what I will do:
Have my own select() function, instead of prepare a SIGSELECT signal
event, preare a “pulse cod for my select PULSE event”.
call _select_event() with this “pulse event”, and the block function
will be the good old _select_receive() guy.
The _select_receive() is the central block point, which will do it’s
own work, except return to caller if “pulse code pulse_select” comming
in…
Could this solve your problem ?
I realize _select_event() is not a documented function, but hey,
neither does _select_receive()
-xtang
“Xiaodan Tang” <xtang@qnx.com> schrieb im Newsbeitrag
news:ah9eh0$k8c$1@nntp.qnx.com…
Peter Weber <> pw@dolphin.de> > wrote:
Thanks very much Xiaodan,
I agree that the client can open multiple channel and in the API I will
have
no idea about
which channel to use. The reason for reuse of the channel in this case
is,
the applications ported from
Q4 to NTO are designed to have a single point for blocking using
_select_receive().
We use exactly the same structure as you as a client handle, but we use
_select_receive() from
Q4 in the clients to use a central blocking point. Changes in this
design
would result
in a complete recoding of all client processes.
Now I will try an aproach with the info->chid information.Ah, now I see where you heading to, the Old Good _select_receive() >
So you want to select() and MsgReceive() at sametime…Good thing we post library source on web, so you could know exactly
how “select()” works under NTO. Take a look here:http://cvs/cgi-bin/product-cvsweb.cgi/lib/
xopen/select.c
qnx/select_event.c
qnx/select_block.cIn a short, “select.c” prepare a sigevent (a SIGSELECT signal event),
and call _select_event() with this “event”, and a block funciton
“_select_block()” (in select_block.c)_select_event() simply fire the event cross fd (coid), and then
block into _select_block()._select_block() basically go into sigtimedwait() to wait that SIGSELECT
comming in…So here is what I will do:
Have my own select() function, instead of prepare a SIGSELECT signal
event, preare a “pulse cod for my select PULSE event”.call _select_event() with this “pulse event”, and the block function
will be the good old _select_receive() guy.The _select_receive() is the central block point, which will do it’s
own work, except return to caller if “pulse code pulse_select” comming
in…
Yep…beautyful…this makes total sense…my messages are filtered between
fd events and
pulses (not directly for me) and I get exactly what I want. Hmm…very
elegant Xiaodan
May I will think about a common wrapper lib for that and I will post it here
for every one
who wants it.
Could this solve your problem ?
I realize _select_event() is not a documented function, but hey,
neither does _select_receive() >
For me - this function was one of the most elegant things in Q4!
Easy to use, open to all sides, generic interface to the rest of the
world…
This was the most elegant aproach for many applications.
Thank you very much for your help Xiaodan!
cheers, Peter