Looking for options or if there is an issue…
I’m porting the Linux UPnP SDK (originally from Intel, now on Sourceforge)
and have run into a usage of send(…) to a socket that is specifying a
flag of MSG_NOSIGNAL.
The usage of this is to prevent an EPIPE signal from being generated
but alas this isn’t supported on Nto. The window of opportunity for
this issue is very small but since it has been explicitly coded it means
it has probably been run into.
Any ideas?
Thanks,
Jay
So,
Is there a trick to getting answers? Its been 5 days now and I’m still
used to QUICS where we got answers (or at least an acknowledgment)
in a day or two… and right now QNX sales is working on us for why
we need to go with Nto instead of another OS!
Back to my question in this posting (there are 3 others posted also that I
don’t have any answers on - 1 is critical since I keep dumping io-net!)
MSG_NOSIGNAL for recv() and send() is listed as both BSD4.4 and
POSIX 1003.1g draft.
Where is it since QNX6 claims compliance with the POSIX standard and
it is based on BSD?
I realize the importance in the Linux world because of some major kernel
problems in the past with EPIPE arriving before all the data was read,
I realize I can ignore the signal, but I would still like an answer!
Jay
Jay Hogg wrote in message <9kajq8$eaq$1@inn.qnx.com>…
Looking for options or if there is an issue…
I’m porting the Linux UPnP SDK (originally from Intel, now on Sourceforge)
and have run into a usage of send(…) to a socket that is specifying a
flag of MSG_NOSIGNAL.The usage of this is to prevent an EPIPE signal from being generated
but alas this isn’t supported on Nto. The window of opportunity for
this issue is very small but since it has been explicitly coded it means
it has probably been run into.Any ideas?
Thanks,
Jay
Jay & Mario & QSSL:
What ever happened to the “medium” level of support that was “being worked on”
some months back? I asked this in another newgroup but have heard nothing there
either.
Mario Charest wrote:
“Jay Hogg” <> jh@fastlane.net.r-e-m-o-v-e> > wrote in message
news:9kor2h$2n0$> 1@inn.qnx.com> …
So,
Is there a trick to getting answers? Its been 5 days now and I’m still
used to QUICS where we got answers (or at least an acknowledgment)
in a day or two… and right now QNX sales is working on us for why
we need to go with Nto instead of another OS!
Things have change Jay. For the moment to get the same level of response
(well not quite) you remember from QUICS you need to have Premium
support.Back to my question in this posting (there are 3 others posted also that I
don’t have any answers on - 1 is critical since I keep dumping io-net!)MSG_NOSIGNAL for recv() and send() is listed as both BSD4.4 and
POSIX 1003.1g draft.Where is it since QNX6 claims compliance with the POSIX standard and
it is based on BSD?I realize the importance in the Linux world because of some major kernel
problems in the past with EPIPE arriving before all the data was read,
I realize I can ignore the signal, but I would still like an answer!Jay
Jay Hogg wrote in message <9kajq8$eaq$> 1@inn.qnx.com> >…
Looking for options or if there is an issue…I’m porting the Linux UPnP SDK (originally from Intel, now on
Sourceforge)
and have run into a usage of send(…) to a socket that is specifying a
flag of MSG_NOSIGNAL.The usage of this is to prevent an EPIPE signal from being generated
but alas this isn’t supported on Nto. The window of opportunity for
this issue is very small but since it has been explicitly coded it means
it has probably been run into.Any ideas?
Thanks,
Jay
\
“Jay Hogg” <jh@fastlane.net.r-e-m-o-v-e> wrote in message
news:9kor2h$2n0$1@inn.qnx.com…
So,
Is there a trick to getting answers? Its been 5 days now and I’m still
used to QUICS where we got answers (or at least an acknowledgment)
in a day or two… and right now QNX sales is working on us for why
we need to go with Nto instead of another OS!
Things have change Jay. For the moment to get the same level of response
(well not quite) you remember from QUICS you need to have Premium
support.
Back to my question in this posting (there are 3 others posted also that I
don’t have any answers on - 1 is critical since I keep dumping io-net!)MSG_NOSIGNAL for recv() and send() is listed as both BSD4.4 and
POSIX 1003.1g draft.Where is it since QNX6 claims compliance with the POSIX standard and
it is based on BSD?I realize the importance in the Linux world because of some major kernel
problems in the past with EPIPE arriving before all the data was read,
I realize I can ignore the signal, but I would still like an answer!Jay
Jay Hogg wrote in message <9kajq8$eaq$> 1@inn.qnx.com> >…
Looking for options or if there is an issue…I’m porting the Linux UPnP SDK (originally from Intel, now on
Sourceforge)
and have run into a usage of send(…) to a socket that is specifying a
flag of MSG_NOSIGNAL.The usage of this is to prevent an EPIPE signal from being generated
but alas this isn’t supported on Nto. The window of opportunity for
this issue is very small but since it has been explicitly coded it means
it has probably been run into.Any ideas?
Thanks,
Jay
\
Ahh… Nice to see old faces again!
I saw that posting on the “medium” level but it, like a quite a few of other
postings, just died off with no response.
I don’t mind paying for a “medium level” of support assuming I can get
some! I typically used only QUICS with a few occasional emails to
Steve or John when all hell broke loose on a problem they were
chasing.
I can also see why it is hard to get responses with a large newsgroup
like “os” that is currently showing 4000 postings 
It took a little
learning
on how stuff was partitioned but “.fsys” “.kernel” “.util” “.net” “.tcpip”
made
a lot of sense and it was much easier to go see if somebody else had
the problem. They were also the “pay to post” (I hated points!) groups
that typically had the experienced developers from both QSSL and the
outside… ah, the good old days.
Mario - we need to catch up sometime!
Jay
Dean Douthat wrote in message <3B6FF819.FAC567C4@faac.com>…
Jay & Mario & QSSL:
What ever happened to the “medium” level of support that was “being worked
on”
some months back? I asked this in another newgroup but have heard nothing
there
either.Mario Charest wrote:
“Jay Hogg” <> jh@fastlane.net.r-e-m-o-v-e> > wrote in message
news:9kor2h$2n0$> 1@inn.qnx.com> …
So,
Is there a trick to getting answers? Its been 5 days now and I’m still
used to QUICS where we got answers (or at least an acknowledgment)
in a day or two… and right now QNX sales is working on us for why
we need to go with Nto instead of another OS!
Things have change Jay. For the moment to get the same level of response
(well not quite) you remember from QUICS you need to have Premium
support.Back to my question in this posting (there are 3 others posted also
that I
don’t have any answers on - 1 is critical since I keep dumping io-net!)MSG_NOSIGNAL for recv() and send() is listed as both BSD4.4 and
POSIX 1003.1g draft.Where is it since QNX6 claims compliance with the POSIX standard and
it is based on BSD?I realize the importance in the Linux world because of some major
kernel
problems in the past with EPIPE arriving before all the data was read,
I realize I can ignore the signal, but I would still like an answer!Jay
Jay Hogg wrote in message <9kajq8$eaq$> 1@inn.qnx.com> >…
Looking for options or if there is an issue…I’m porting the Linux UPnP SDK (originally from Intel, now on
Sourceforge)
and have run into a usage of send(…) to a socket that is specifying
a
flag of MSG_NOSIGNAL.The usage of this is to prevent an EPIPE signal from being generated
but alas this isn’t supported on Nto. The window of opportunity for
this issue is very small but since it has been explicitly coded it
means
it has probably been run into.Any ideas?
Thanks,
Jay
\
“Jay Hogg” <Jay.Hogg@t-netix.com.r-e-m-o-v-e> wrote in message
news:9kotg8$44d$1@inn.qnx.com…
Ahh… Nice to see old faces again!
Definitely nice to see you around here too.
I saw that posting on the “medium” level but it, like a quite a few of
other
postings, just died off with no response.I don’t mind paying for a “medium level” of support assuming I can get
some! I typically used only QUICS with a few occasional emails to
Steve or John when all hell broke loose on a problem they were
chasing.
I have a diner scheduled with Steve, been waiting till last summer
I can also see why it is hard to get responses with a large newsgroup
like “os” that is currently showing 4000 postings >
learning
on how stuff was partitioned but “.fsys” “.kernel” “.util” “.net” “.tcpip”
made
a lot of sense and it was much easier to go see if somebody else had
the problem. They were also the “pay to post” (I hated points!) groups
that typically had the experienced developers from both QSSL and the
outside… ah, the good old days.
I agree, but QSSL is changing and getting bigger. I miss the “old days”
but am trying to go with the flow…
The support was once a huge advantage over other OSes. It’s less and
less true today I guess, but I think it’s still above the other
Mario - we need to catch up sometime!
I haven’t heard when the next conference is going to be , lol!
I’ve kept in touch with Chris a bit. I’ll take some time this week
to send you story of my life
The usual way is to simply set signal(SIGPIPE, SIG_IGN).
This is pocess wide however. This wll cause the send()
to fail with EPIPE instead of being hit with the signal.
-seanb
Jay Hogg <jh@fastlane.net.r-e-m-o-v-e> wrote:
: Looking for options or if there is an issue…
: I’m porting the Linux UPnP SDK (originally from Intel, now on Sourceforge)
: and have run into a usage of send(…) to a socket that is specifying a
: flag of MSG_NOSIGNAL.
: The usage of this is to prevent an EPIPE signal from being generated
: but alas this isn’t supported on Nto. The window of opportunity for
: this issue is very small but since it has been explicitly coded it means
: it has probably been run into.
: Any ideas?
: Thanks,
: Jay