Re: optimizing fork/exec in vendor source

eric wrote: > Exactly how do you propose to implement posix_spawnattr_setsigdefault > without understanding cygwin internals, and given the fact that native > Windows API is woefully lacking in sigset_t coding? in the startup code for the new process, i'd call signal() (or similar) to set the defa

Re: optimizing fork/exec in vendor source

On Sat, Oct 11, 2008 at 1:26 AM, Christopher Faylor <[EMAIL PROTECTED]> wrote: >>this seems to be an easy problem in cygwin (at least, in comparison to >>fork). and would fix one of the biggest problems with cygwin (or at >>least cygwin bash). who has to hold the copyright? > > It is not an "easy

Re: optimizing fork/exec in vendor source

eric wrote: > No, changing bash to use CreateProcess is not the answer. The real > question is whether someone with copyright assignment is willing to write > posix_spawn[p], and write it more efficiently than forking, this seems to be an easy problem in cygwin (at least, in comparison to fork).

optimizing fork/exec in vendor source

hi guys, i think cygwin is great, and i'd like it to be more useful to me. my work for the past year has been porting daemons to windows. so i'm familiar with the fork problem. i've read a little about how cygwin does a lot of work to make fork work. -- and to make it work without having to ch