SELECT_FLAG_SRVEXCEPT

I’ve run across what appears to be another problem in select_attach.
The
symptom is that one of my apps mysteriously exits when integrated into
out
final system. It turned out that the problem was caused by my attempt
to
use the SELECT_FLAG_SRVEXCEPT feature. Concerning that flag, the docs
say
“In this case, fd is ignored.” That appears to be not quite true: in
_select_rearm an attempt is made to do a MsgSend with an _IO_NOTIFY
message
to the specified fd, and if the MsgSend fails the process exits! (Right

after the comment that says “@@@ handle error condition.”) Since the
“fd is
ignored” I stuck a zero in my call to select_attach, apparently
resulting in
messages being sent to stdin. When my app was started early in the boot

process, before anyone had opened stdin, it would run for a few seconds
and
then exit(0), even though the last thing it had done was call
thread_pool_start, which didn’t return — very disconcerting! Does
anybody
know if this problem has been fixed for the next release?

Murf

John,

Drop me an e-mail please with the details. I know that we had
looked at some of the problems, but I can’t remember if they had
all been resolved.

Thanks
Thomas (thomasf@)
John A. Murphy <murf@perftech.com> wrote:

I’ve run across what appears to be another problem in select_attach.
The
symptom is that one of my apps mysteriously exits when integrated into
out
final system. It turned out that the problem was caused by my attempt
to
use the SELECT_FLAG_SRVEXCEPT feature. Concerning that flag, the docs
say
“In this case, fd is ignored.” That appears to be not quite true: in
_select_rearm an attempt is made to do a MsgSend with an _IO_NOTIFY
message
to the specified fd, and if the MsgSend fails the process exits! (Right

after the comment that says “@@@ handle error condition.”) Since the
“fd is
ignored” I stuck a zero in my call to select_attach, apparently
resulting in
messages being sent to stdin. When my app was started early in the boot

process, before anyone had opened stdin, it would run for a few seconds
and
then exit(0), even though the last thing it had done was call
thread_pool_start, which didn’t return — very disconcerting! Does
anybody
know if this problem has been fixed for the next release?

Murf

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Core OS Technology Group
(613)-591-0931 http://www.qnx.com/