<div dir="ltr"><div dir="ltr">Ah, cool. That makes total sense. <div><br></div><div>Now I'm having issues trying to configure the ruby module with using my Ruby installation inside my local directory (using the "asdf" ruby plugin), but I will create a GitHub issue for this. (autoconf's ruby rbconfig looks ok to me) :</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div>$ ./configure ruby --module=ruby-2.6.0  --ruby=/home/megatux/.asdf/installs/ruby/2.6.0/bin/ruby</div></div></div><div><div><div>configuring Ruby module</div></div></div><div><div><div>checking for Ruby library ... not found</div></div></div><div><div><div>checking for Ruby library in /home/megatux/.asdf/installs/ruby/2.6.0/lib ... not found</div></div></div><div><div><div><br></div></div></div><div><div><div>./configure: error: no Ruby found.</div></div></div></blockquote><div dir="ltr"><div><br></div><div>Regards</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 29 de ene. de 2019 a la(s) 17:00, Valentin V. Bartenev (<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday 29 January 2019 16:07:55 <a href="mailto:megatux@gmail.com" target="_blank">megatux@gmail.com</a> wrote:<br>
> I see. That should work, thanks.<br>
> Now, doesn't this compile-time list of available runtimes limit the<br>
> "dynamic" nature of the service?<br>
> e.g. I'm thinking in the common scenario of upgrading one of the runtimes<br>
> because of a security update.<br>
> This involves starting a new process and move all of its apps & listeners,<br>
> right?<br>
> <br>
[..]<br>
<br>
Unit has much more advanced architecture then most application servers.<br>
<br>
Unit contains an asynchronous router process, that deals with connections<br>
and doesn't deal with laguages.  In order to run an application, another<br>
process is forked.  Only after the fork, it loads a required application<br>
module in this new process.  This application process then starts<br>
communication with the router process to serve requests and responses.<br>
So, the modules are loaded only inside the application processes that<br>
don't deal with client connections.<br>
<br>
When you have to update your application module because of security issue,<br>
you don't need to restart the whole Unit.<br>
<br>
This allows to handle this scenario gracefully with restarting only<br>
application processes without touching listening sockets and connections.<br>
<br>
Currently Unit scans modules directory only once in order to know<br>
what languages and versions are available.  In future, it will be able<br>
to rescan this directory, and that will allow not only updating of<br>
existing modules, but also adding new languages and versions dynamically.<br>
<br>
  wbr, Valentin V. Bartenev<br>
<br>
_______________________________________________<br>
unit mailing list<br>
<a href="mailto:unit@nginx.org" target="_blank">unit@nginx.org</a><br>
<a href="https://mailman.nginx.org/mailman/listinfo/unit" rel="noreferrer" target="_blank">https://mailman.nginx.org/mailman/listinfo/unit</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>-----------------------------------------------------<br>   .^. In an open world, who needs windows or gates?<br>   /V\   <a href="http://www.megatux.me/" target="_blank">Cristian Molina</a><br>  //  \\   GNU/Linux User #73047, Ubuntu User # 14733<br> /( _ )\       Merlo, San Luis - Argentina   <br>  ^^ ^^ ---------------------------------------------</div></div></div></div></div>