From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Kjeldaas Subject: Re: Avoiding threads in the daemon Date: Sat, 20 Dec 2014 01:11:47 +0100 Message-ID: References: <87mw6lym95.fsf@gnu.org> <54946C7A.9020804@logicblox.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1537054828==" Return-path: In-Reply-To: <54946C7A.9020804@logicblox.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nix-dev-bounces@lists.science.uu.nl Errors-To: nix-dev-bounces@lists.science.uu.nl To: Eelco Dolstra Cc: guix-devel , =?UTF-8?Q?Ludovic_Court=C3=A8s?= , nix-dev List-Id: guix-devel.gnu.org --===============1537054828== Content-Type: multipart/alternative; boundary=20cf30207f5402daa6050a9aad12 --20cf30207f5402daa6050a9aad12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 19, 2014 at 7:20 PM, Eelco Dolstra wrote: > Hi, > > On 18/12/14 17:32, Ludovic Court=C3=A8s wrote: > > > Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which > > uses std::thread just for convenience) should be reverted, along with > > the subsequent commits to that file; then commit 524f89 can be reverted= . > > I really don't want to get rid of threads because they're useful and I > want to > use them more in the future (e.g. build.cc would be much simpler if it us= ed > threads rather than the current event-driven approach; nix-daemon could > handle > client connections with a thread rather than a process; etc.). > > I see a few ways to get PID namespaces back: > > * Do a regular fork followed by clone(... | CLONE_NEWPID | CLONE_PARENT) > (after > which the intermediate process can exit). > > * Call setuid/setgid via syscall() to bypass the locking in the Glibc > wrappers. > However, there might be other problematic functions so this is not a grea= t > solution. > > * Get the Glibc folks to provide a way to run at-fork handlers with > clone(). > > Clearly the first option is the easiest. > > There is a 4th solution - use a fork()-service. What you do is you fork() a specific child, the fork()-service, when you start your process, before any mutex is held and while you control the full state of your program. You then communicate with this service using pipes, or your favorite IPC mechanism. The fork()-service never starts any thread, and can safely fork off any child you need. Alexander --20cf30207f5402daa6050a9aad12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 19, 2014 at 7:20 PM, Eelco Dolstra <eelco.dolstr= a@logicblox.com> wrote:
Hi,=

On 18/12/14 17:32, Ludovic Court=C3=A8s wrote:

> Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which=
> uses std::thread just for convenience) should be reverted, along with<= br> > the subsequent commits to that file; then commit 524f89 can be reverte= d.

I really don't want to get rid of threads because they're us= eful and I want to
use them more in the future (e.g. build.cc would be much simpler if it used=
threads rather than the current event-driven approach; nix-daemon could han= dle
client connections with a thread rather than a process; etc.).

I see a few ways to get PID namespaces back:

* Do a regular fork followed by clone(... | CLONE_NEWPID | CLONE_PARENT) (a= fter
which the intermediate process can exit).

* Call setuid/setgid via syscall() to bypass the locking in the Glibc wrapp= ers.
However, there might be other problematic functions so this is not a great = solution.

* Get the Glibc folks to provide a way to run at-fork handlers with clone()= .

Clearly the first option is the easiest.


There is a 4th solution - use a fork()-service. What= you do is you fork() a specific child, the fork()-service, when you start = your process, before any mutex is held and while you control the full state= of your program.=C2=A0 You then communicate with this service using pipes,= or your favorite IPC mechanism.=C2=A0 The fork()-service never starts any = thread, and can safely fork off any child you need.

Alexander
--20cf30207f5402daa6050a9aad12-- --===============1537054828== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev --===============1537054828==--