[erlang-questions] Difference between enif_schedule_dirty_nif and driver_async?

[Steve Vinoski]

On Sat, Jun 21, 2014 at 12:23 PM, Max Lapshin <max.lapshin@REDACTED> wrote:

> No, external port is not an easy thing.
>
> I've tried to do so, but stopped: too many work is done in C around
> packing/unpacking logic and commands. It is much easier to write small C
> code in C and wrapper in erlang: video is decoded to plain binaries, then
> coded back into binaries.
>
> Everything is running in a separate node. So transcoder node is a separate
> unix process with all it's threads. Different streams are transcoded in
> different processes.
>
> Steve, thanks for the explanation. I didn't knew how many dirty threads
> are there.  There is flag: CPU or IO bound nif. How does this flag affects
> scheduling?
>

If you specify CPU-bound, the job is run on a dirty CPU scheduler; if
I/O-bound, the job is run on a dirty I/O scheduler. The dirty CPU and dirty
I/O schedulers reside in different pools.

The number of dirty I/O schedulers is 10 by default, same as the number of
threads in the async pool. You can change it via the +SDio option to erl
(the explanation of which unfortunately appears to be missing from the erl
man page, I'll submit a patch for that).

The number of dirty CPU schedulers is aligned with the number of regular
scheduler threads to prevent them from having too much of an impact on the
regular schedulers. The number of dirty I/O schedulers can be larger, but
that assumes those threads are I/O-bound and are thus not that busy.The
submission of jobs to the dirty CPU threads vs dirty I/O threads is
entirely up to the NIF developer; the code those two sets of threads run
inside the emulator is the same as far as NIF execution goes. A developer
could send dirty CPU jobs to the dirty I/O schedulers and vice versa; the
runtime does nothing to try to govern or prevent this.

--steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140621/dec982d7/attachment.htm>