search for: afbcd070

...> > (As an aside: Ideally in future we'll allow the thread model to be > specified by the plugin dynamically. It's one of the things I thought > I had listed in the TODO file - it wasn't there so I've added it now.) That's because we already have that: See commit afbcd070 and nearby. So I'll just revert your TODO change :) > >> But it does raise an interesting point - if we hit platforms that are >> unable to support atomic CLOEXEC, one possibility is a patch that forces >> SERIALIZE_ALL_REQUESTS as the maximum parallelism allowed on that...

On 7/31/19 4:31 PM, Eric Blake wrote: > The rate filter is potentially opening fds in one thread while another > thread is processing a fork() in the plugin. Although the file is not > open for long, we MUST atomically use CLOEXEC to avoid fd leaks. This > one is a bit harder to observe using only the sh plugin, because the > window is small; you'll have better success at

Rich pointed out that making thread_model dynamic even for plugins makes some sense, so here is the code for doing it for 'sh'. I'm less confident on how to do it for OCaml and Rust (not to mention that those allow the plugin to already compile in their model, rather than the language binding glue forcing a model). The other languages (lua, perl, python, ruby) still need to be