| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
a top level more independently configured package.
|
| |
|
|
| |
sequence.
|
| | |
|
| |
|
|
| |
fcntl support and an external fcntl handler for sockets.
|
| |
|
|
|
| |
IO handlers scheme that was implemented originally just to support
sockets. The file system IO switch is more general and works fine.
|
| |
|
|
| |
NULL pointer.
|
| |
|
|
| |
all conflicts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
RTEMS permits using the SO_SNDTIMEO and SO_RCVTIMEO socket options to
set a timeout for most socket I/O operations. However, in RTEMS
4.0.0, those options do not affect connect or accept. I don't know of
any way to put a timeout on those calls in RTEMS 4.0.0; can anybody
point to one.
Since it is frequently useful to have a timeout on accept, and
sometimes useful to have a timeout on connect shorter than the BSD
system default of 75 seconds, the following patch causes SO_RCVTIMEO
to affect connect and accept.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remember the test to see if a socket could be read and written at
the same time by two different tasks? I discovered that if both
tasks attempt to close the socket a panic can occur from inside the
BSD code.
Closing the same socket twice from two different threads is
certainly an error, but a panic is not the greatest error reporting
method :-)
The following small change to the socket close routine should reduce
the chances of the panic.
|
| | |
|
| | |
|
| | |
|
| |
|
