[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils-bug
Subject:    bug#14752: sort fails to fork() + execlp(compress_program) if overcommit limit is reached
From:       Pádraig Brady <P () draigBrady ! com>
Date:       2013-07-02 0:10:25
Message-ID: 51D21A71.3010008 () draigBrady ! com
[Download RAW message or body]

On 07/02/2013 12:45 AM, Petros Aggelatos wrote:
> Following up on this issue it seems that posix_spawn() cannot be used,
> at least not trivially. The issue is that posix_spawn decides if it will
> spawn the new process with fork() of vfork() based on some conditions,
> one of which is if file_actions is NULL.
> 
> http://repo.or.cz/w/glibc.git/blob/HEAD:/sysdeps/posix/spawni.c#l105

Ugh, that's unfortunate :(
That restriction seems a bit too harsh on cursory glance.

> For the temp compression to work it is nessesary to pass the file
> descriptors of the pipe from the parent to the child. I'm not sure how
> to proceed, I found this relevant thread that proposes to relax the
> restrictions and use vfork more often:
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=10354
> 
> And this thread http://sourceware.org/ml/libc-help/2010-10/msg00001.html
> of someone having the same problem and proposing two solutions. Solution
> #1 seems to me that adds a lot of complexity. Solution #2 is hacky, and
> I'm not aware if there are unwanted sideffects of using the enviroment
> to transfer the FDs.

Thanks for taking the time to find these previous discussions.

Perhaps the best first approach is to use vfork() directly,
so see if we actually do hit limitations in practice.
If not, then perhaps we could adjust the gnulib spawni.c code
accordingly, and add that as input to the above glibc bug
for eventual incorporation into glibc.

cheers,
Pádraig.



[prev in list] [next in list] [prev in thread] [next in thread]