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
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
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.
Which
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-workers
I really consider the use of Cygwin's spawn() deprecated and I'm not
really interested in spending time on it.
Why ? It is a way to significantly increase performance. And, before Cygwin
has posix_spawn(), it is the only way to do it.
I was following various fork() discussions, Microsoft is
Hello!
Sorry for silence, i was completely busy with other interesting stuff...
By this time i have calmed down and remade my thoughts...
First, since i am interested, i will conduct the research about that code
between fork() and exec() and try to implement some test cases for it.
Perhaps
On Fri, 2013-08-16 at 20:59 +0400, Pavel Fedin wrote:
Friday, August 16, 2013, 19:19:58 you wrote:
Also, when I'm making changes to the exec() code I don't spend a lot of
time worrying about spawn() so it is possible that it will be broken
from time to time and, in fact, I think you
On Fri, 2013-08-16 at 13:30 -0400, Christopher Faylor wrote:
On Fri, Aug 16, 2013 at 01:12:28PM -0400, Paul Smith wrote:
On Fri, 2013-08-16 at 20:59 +0400, Pavel Fedin wrote:
Friday, August 16, 2013, 19:19:58 you wrote:
Also, when I'm making changes to the exec() code I don't spend a lot of
Hello, Paul.
Friday, August 16, 2013, 22:18:31 you wrote:
Presumably make works at least 99% correctly on Windows using spawn*().
I don't doubt at all that the patch actually works great with most uses
of make in Cygwin. However, I would rather be 100% correct and slower
than 99% correct
From: Paul Smith psm...@gnu.org
Date: Fri, 16 Aug 2013 14:18:31 -0400
Cc: bug-make@gnu.org
So, the question is very simple: is it technically possible to ensure
that the operations make takes today in the child between fork and exec
can be handled properly in a spawn-based
On Fri, Aug 16, 2013 at 02:18:31PM -0400, Paul Smith wrote:
On Fri, 2013-08-16 at 13:30 -0400, Christopher Faylor wrote:
On Fri, Aug 16, 2013 at 01:12:28PM -0400, Paul Smith wrote:
On Fri, 2013-08-16 at 20:59 +0400, Pavel Fedin wrote:
Friday, August 16, 2013, 19:19:58 you wrote:
Also, when
On Fri, 2013-08-16 at 22:52 +0400, Pavel Fedin wrote:
Exactly, hence the reason for my question. I'm not interested in adding
this if, when it's enabled, things don't work correctly.
On the other hand I'm not sure it's not possible to get things working
correctly. Or, perhaps it's
Hello!
I tried to explain that in my first response: 'fork' has a certain
semantics and implements requirements that 'spawn' does not.
Stop stop stop... Just to avoid misunderstanding here...
fork() alone cannot be replaced with spawn(), yes. But as fas as i
understand, make does not use
Hello!
Once again, please make this a run-time option, off by default,
activated by a command-line argument. Not a compile-time feature.
Using spawn by default for Cygwin is a non-starter.
Runtime ??? I am sorry, but what's the sense ?
First, this will not work well, because many
From: Pavel Fedin p.fe...@samsung.com
Cc: bug-make@gnu.org
Date: Tue, 06 Aug 2013 10:46:51 +0400
Runtime ??? I am sorry, but what's the sense ?
I tried to explain that in my first response: 'fork' has a certain
semantics and implements requirements that 'spawn' does not. Since
Cygwin is a
Hello! I have found and fixed the problem. It appeared to be PATH issue.
fork()-based code temporary sets 'environ' variable to child's environment,
which appears to contain current directory. EMX code didn't do that.
The problem gets triggered only if you try to call something which is not
Date: Mon, 5 Aug 2013 21:34:31 +0400
From: Pavel Fedin pavel_fe...@mail.ru
fork()-based code temporary sets 'environ' variable to child's environment,
which appears to contain current directory. EMX code didn't do that.
The problem gets triggered only if you try to call something which
17 matches
Mail list logo
