[erlang-bugs] efile_drv & async thread key

[Rick Reed]

On Thu, Aug 15, 2013 at 9:34 AM, Patrik Nyblom <pan@REDACTED> wrote:

>  Yes, one example is process exit, where close definitely should not be
> intermingled
> with other file operations from other threads that are ongoing. That
> definitely happens if
> you round robin the file descriptors.
>

Perhaps the close could be enqueued on the descriptor work queue but not
issued to
the async thread queue until any outstanding ops have finished, though it
doesn't look
like the descriptor currently keeps track of how many async ops are
outstanding.


> Yes, probably. It is not safe though, especially compressed files in
> combination with
> processes getting exit (kill) signals during the file operations may core
> the VM.
>

In our case, the file procs run forever, so I think our risk will be low on
this particular
system.  I've enabled the behavior via an env var, so we won't be running
this on the
rest of our systems.

With better distribution of the FD's maybe you can get as good results as
> with
> the round robin without risks?
>

Unfortunately not.  The only way to ensure that there wouldn't a noticeable
difference
in load between different async threads would be to either have far too
many or far
too few async threads.

Rr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130815/a8ea16b2/attachment.htm>