I have an application which uses select() to monitor the file descriptors
for stdio and 2 sockets. It works fine on the development PC. On the target
single-board computer w/ a watered down OS image, select() is not returning
when data is sent to the two sockets, but it does when data is sent to
stdio. Furthermore, if data was sent to the sockets and then a key is
pressed (thus triggering select through the stdio), the sockets are present
in the file descriptor set. So select saw them but did not return?!?
I have an application which uses select() to monitor the file
descriptors for stdio and 2 sockets. It works fine on the development
PC. On the target single-board computer w/ a watered down OS image,
select() is not returning when data is sent to the two sockets, but it
does when data is sent to stdio. Furthermore, if data was sent to the
sockets and then a key is pressed (thus triggering select through the
stdio), the sockets are present in the file descriptor set. So select
saw them but did not return?!?
Any insight on this would be appreciated…
Ricardo
Actually, just found out that if I comment out the stdio from the file
descriptors, everything works fine. SO… its the stdio that is somehow
messing things up for the socket descriptors.
I have an application which uses select() to monitor the file
descriptors for stdio and 2 sockets. It works fine on the development
PC. On the target single-board computer w/ a watered down OS image,
select() is not returning when data is sent to the two sockets, but it
does when data is sent to stdio. Furthermore, if data was sent to the
sockets and then a key is pressed (thus triggering select through the
stdio), the sockets are present in the file descriptor set. So select
saw them but did not return?!?
Any insight on this would be appreciated…
Ricardo
Actually, just found out that if I comment out the stdio from the file
descriptors, everything works fine. SO… its the stdio that is somehow
messing things up for the socket descriptors.
Ricardo
And… only happens if stdio is redirected to /dev/ser1. If stdio is a
telnet terminal it works fine.
I have an application which uses select() to monitor the file descriptors
for stdio and 2 sockets. It works fine on the development PC. On the target
single-board computer w/ a watered down OS image, select() is not returning
when data is sent to the two sockets, but it does when data is sent to
stdio. Furthermore, if data was sent to the sockets and then a key is
pressed (thus triggering select through the stdio), the sockets are present
in the file descriptor set. So select saw them but did not return?!?
Any insight on this would be appreciated…
Which OS & version? Which serial port driver? Which TCP/IP stack?
I have an application which uses select() to monitor the file
descriptors for stdio and 2 sockets. It works fine on the development
PC. On the target single-board computer w/ a watered down OS image,
select() is not returning when data is sent to the two sockets, but
it does when data is sent to stdio. Furthermore, if data was sent to
the sockets and then a key is pressed (thus triggering select through
the stdio), the sockets are present in the file descriptor set. So
select saw them but did not return?!?
Any insight on this would be appreciated…
Which OS & version? Which serial port driver? Which TCP/IP stack?
-David
OS: QNX 6.2
Serial Driver: devc-ser8250
TCPIP: ttcpip
Only occurs when executing the app from the redirected (/dev/console =
/dev/ser1) terminal. AND if I give select() a timeout, it does not trigger
on the redirected terminal, but it does on a telnet terminal.