On Mon, Sep 02, 2013 at 06:40:01PM -0400, David Boyce wrote:
> 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 runni
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
er Russia
> -Original Message-
> From: Ray Donnelly [mailto:mingw.andr...@gmail.com]
> Sent: Monday, September 02, 2013 2:58 PM
> To: Pavel Fedin
> Cc: Christopher Faylor; bug-make@gnu.org; Eli Zaretskii
> Subject: Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated
>
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
> 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
On Thu, Aug 22, 2013 at 05:48:21PM +0300, Eli Zaretskii wrote:
>> From: Pavel Fedin
>> Date: Thu, 22 Aug 2013 09:43:09 +0400
>> Cc: bug-make@gnu.org
>>
>> What if we implement posix_spawn() for Cygwin ? Would you like
>> that ?
>
>If Paul accepts that for platforms other than Cygwin, I certainly
> From: Pavel Fedin
> Date: Thu, 22 Aug 2013 09:43:09 +0400
> Cc: bug-make@gnu.org
>
> What if we implement posix_spawn() for Cygwin ? Would you like
> that ?
If Paul accepts that for platforms other than Cygwin, I certainly
won't mind. But please wait for Paul and Christopher to provide their
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 thi
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 i
> Date: Fri, 16 Aug 2013 22:52:55 +0400
> From: Pavel Fedin
> Cc: Christopher Faylor ,
> bug-make@gnu.org
>
> To me current situation looks non-constructive. You say: "Current
> implementation works, new implementation theoretically may fail
> (because it's new), so we
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:
>> >>
> From: Paul Smith
> 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 implementation?
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% cor
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 spe
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
>>>time worrying about spawn() so it is possible that it wi
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 yo
Hello, Christopher.
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 actually noticed some
> breakage in the c
On Wed, Aug 07, 2013 at 12:52:48PM +0400, Pavel Fedin wrote:
>> 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 spaw
Hello, Denis.
Sunday, August 11, 2013, 10:54:25 you wrote:
> As a user, i would be fully happy if the behavior could be driven by the
> MAKE_USE_SPAWN env. var. (and a similar env. var. in case the default is
> spawn).
> Associated command line options would be unnecessary, but perhaps needed fo
On 2013-08-07 10:52, Pavel Fedin wrote:
> Perhaps some more testing would convince you. Actually i have
> sent the new patch to Denis Excoffier (who reported the bug), but he doesn't
> reply for some reason. If there'll be no response for some more time, i'll
> retry posting the patch on Cygwin M
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 f
> From: Pavel Fedin
> 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 Posix environm
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 makefi
> Date: Mon, 5 Aug 2013 21:34:31 +0400
> From: Pavel Fedin
>
> 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 in
> yo
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 in
28 matches
Mail list logo
