<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 21, 2014 at 12:23 PM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">No, external port is not an easy thing.</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">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?</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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). </div>
<div><br></div><div>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.</div>
<div><br></div><div>--steve</div></div></div></div>