This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Extend faq.using to discuss fork failures


On Fri, Aug 19, 2011 at 12:01:18PM -0400, Ryan Johnson wrote:
>On 19/08/2011 10:41 AM, Christopher Faylor wrote:
>> I appreciate your thoroughness but I think there are way too many words
>> above.  The FAQ should be solution-oriented.  If it is important to
>> discuss the details behind why fork() fails then maybe another section
>> could be added.  Otherwise, I'd prefer to see something which shows the
>> error messages and then, as briefly as possible, shows solutions.
>> While people do ask "Why does fork fail?", the majority of the askers
>> don't really care.  They are really asking "How do I make Cygwin fork
>> work?"  So, I don't think that it is really FAQ-appropriate to dive
>> too deep here.
>
>I'm definitely a fan of brevity. My main motivation for all the verbage 
>was so that users who read the faq aren't as shocked when they do all of 
>the above and fork still fails more often than they'd like, and so 
>they'd have some idea of which steps are most applicable to their situation.
>
>Two sections might work very well: "How can I prevent fork failures?" 
>and "Why does fork() still fail after I run rebaseall?" Does that sound 
>good to you?

That sounds better, yes.  I think the former should be solution-oriented
and as succinct as possible.  The latter will be something that we can
point to when people claim to have run the former while ignoring any
follow-on text.  (They will, of course, first, have tried to send
html-only email to the list and will have complained to postmaster that
the mailing list software thought they were spammers)

>> And, again, we don't want to tell people to use non-POSIX solutions
>> except as a last resort.  Telling people to rewrite their source code
>> flies in the face of what Cygwin is trying to do.
>>
>> (And, yes, I presciently can hear the argument to the above paragraph
>> coming)
>You would prefer that it remain an unadvertized last resort, then?

Yes.  I would rather not tell people to rewrite their code.

>I guess the idea is less imposing to me after porting lots of code
>between linux/gcc and solaris/suncc.
>
>Off topic: to be honest, I'd *love* it if bash, make, and gcc used
>spawn instead of fork+exec when compiled under cygwin, though I don't
>know how I/O redirection would fit in.

You know about MinGW, right?

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]