On Mon, Sep 2, 2013 at 4:19 PM, Chris Faylor wrote:
> *There is one know issue with fork where dlls in forked processes don't
>
load at the right address and cause cygwin errors. That is usually
> fixed by running the autorebase program.
>
And it is that issue to which I refer. One of my co-work
On Mon, Sep 02, 2013 at 10:32:38AM -0400, David Boyce wrote:
> Slight change of subject ...
> All this arguing has been about the value of spawn as a speed
> enhancement:
> Pro: spawn is way faster!
> Con: but it may destabilize things - we'll stick with slow-but-stable
> fork.
> Whic
> Date: Mon, 2 Sep 2013 10:32:38 -0400
> From: David Boyce
> Cc: Christopher Faylor , bug-make
>
> All this arguing has been about the value of spawn as a speed enhancement:
>
> Pro: spawn is way faster!
> Con: but it may destabilize things - we'll stick with slow-but-stable fork.
>
> Which ig
Slight change of subject ...
All this arguing has been about the value of spawn as a speed enhancement:
Pro: spawn is way faster!
Con: but it may destabilize things - we'll stick with slow-but-stable fork.
Which ignores the fact that Cygwin fork is *not* that stable. In our
experience make -jN r
Hello!
> Did you actually try your patch in a production environment? It breaks
> make -jN, so any efficiency gains are negated by that fact. We tried it
> in MSYS2 and had to remove it.
Huh, this is the first such feedback.
Of course i use it in production environment. Also, it passes make te
Did you actually try your patch in a production environment? It breaks
make -jN, so any efficiency gains are negated by that fact. We tried
it in MSYS2 and had to remove it.
"because they already own the computing world"
... rght.
On Mon, Sep 2, 2013 at 6:45 AM, Pavel Fedin wrote:
>> I real
