[erlang-questions] Yaws's "sendfile" linked-in driver : "stealing control of fd" error

[Steve Vinoski]

On Mon, Apr 18, 2011 at 6:02 AM, Sverker Eriksson
<sverker@REDACTED> wrote:
> On Sun, Apr 17, 2011 at 5:23 PM, zabrane Mikael <zabrane3@REDACTED> wrote:
>>>
>>> Hi OTP team & Steve,
>>>
>>> I'm using the "sendfile" (thanks to Steve Vinoski) linked-in driver
>>> borrowed from "Yaws"
>>> in one of my pet project.
>>>
>>> Today, I noticed this strange error:
>>> =ERROR REPORT==== 17-Apr-2011::20:49:18 ===
>>> driver_select(0x0000000000000c31, 24, ERL_DRV_WRITE, 1) by
>>> sendfile_drv driver #Port<0.3121> stealing control of fd=24 from
>>> output driver tcp_inet #Port<0.10029>
>>>
>>
>>
>
> The error message kind of says it all:
> The driver "sendfile_drv" is calling driver_select() to subscribe for output
> events on file descriptor 24. BUT, driver "tcp_inet" is already subscribing
> to output events on that very same file descriptor 24. Driver "sendfile_drv"
> thus steals the file descriptor from "tcp_inet" as only one port at a time
> can subscribe to a particular file descriptor event.
>
> I think you should consider this as an error. Drivers are not supposed to
> act like this. The normal cause of this is a driver that forgets to deselect
> a file descriptor before closing it. Despite that I would regard
> sendfile_drv as the primary suspect here as the new kid on the block.

Hi Sverker, I agree it's an error in the sendfile driver, but so far
we have no evidence that it results in erroneous transfers or
incorrect data. As I explained earlier, I've only ever seen it under
catastrophic circumstances, but the fatal errors I saw weren't caused
by this issue; rather, this issue was a side effect of the fatal
errors. What Mikael is seeing, though, has nothing to do with fatal
errors, so I think for cases like his it's just a rare and innocuous
error report. I suspect it occurs due to the tcp driver closing the
socket before the sendfile driver has dropped interest in it but
that's only a guess.

I'll see if I can't come up with a way to reliably reproduce this, but
either way it might not be fixable in the current code since the
sendfile driver can't know if or when the tcp driver is also
registered for the socket being writeable. Maybe this can be handled
correctly as part of Tuncer's effort to add the sendfile functionality
directly into Erlang/OTP.

thanks,
--steve