| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Move networking libraries to c/src/exec/libnetworking
* configure.ac: Reflect Moval.
* Makefile.am: Reflect Moval.
* wrapup/Makefile.am: Reflect Moval.
|
|
* rtems/rtems_syscall.c: Changed from O_NONBLOCK to internal
RTEMS_LIBIO_FLAGS_NO_DELAY to avoid O_NONBLOCK/O_NDELAY confusion
and to work with the converted flags.
|
|
|
|
now prototypes the malloc family in stdlib.h. This causes conflicts
with the way the network stack overrides the definitions of malloc.
As best I (being Joel) can tell, commenting stdlib.h out keeps the
files compiling and referencing the desired malloc/free but results
in more warnings.
|
|
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.
|
|
|
|
|
|
|
|
|
