| Age | Commit message (Collapse) | Author |
|---|
|
The tests have to be skipped when the emulator running the tests does
not have any async threads.
|
|
* lukas/erts/sendfile_no_async_pool/OTP-11639:
erts/kernel: sendfile no longer uses async threads
|
|
The bug incorrectly issued driver_select when un-ignoring an fd
for a socket in passive mode, which caused an incorrect error
tuple to be returned when the remote end closed the connection.
|
|
This has been done because a slow client attack is possible if the
async thread pool is used. The scenario is:
Client does a request for a file and then slowly receives the file one
byte at a time. This will eventually fill the async thread pool with blocking
sendfile operations and thus starving the vm of all file operations.
If you still want to use the async threads pool for sendfile an option to
enable it has been introduced.
|
|
|
|
Since stop_select is called at an arbitrary point in the future
it would sometime not be alled before the tcp driver started
selecting on the fd. So now ERL_DRV_USE_NO_CALLBACK is used
so that the stop_select call is never made.
This seems to only have happened OS X.
|
|
The return value from efile_sendfile was not consistent
inbetween platforms. The API should now be working as it
was intended.
OTP-9994
|
|
|
|
|
|
|
|
When sendfile crashes during a send there should be no
error_logger printouts about stolen fds.
|
|
If the socket is closed by the remote end, sendfile
now returns {error,closed}.
|
|
Thanks Tuncer Ayaz
|
|
sendfilev is a richer API which allows us to
do non blocking TCP on solaris. The normal
sendfile API seems to have some issue with
non blocking sockets and the return value of
sendfile.
|
|
|
|
|
|
Since the API for headers/trailers seem to be very awkward to
work with when using non-blocking io the feature is dropped
for now. See unix_efile.c for more details.
|
|
Since sendfile could in theory be used to send to any type
of file descriptor in *nix, it is a better fit to have it
in file.
|
