Mail Archives: cygwin-developers/1998/06/07/14:26:03
>From: newsham AT lava DOT net (Tim Newsham)
>Date: Sun, 7 Jun 1998 10:31:23 -1000 (HST)
>
>> I see another simple solution - functions pinfo::init_from_exec() and
>> hinfo_vec::dup_for_exec() should be removed, and
>> hinfo_vec::linearize_fd_array() should be modified to ignore fds with
>> close_on_exec set. The single line will be modified (hinfo.cc, line 413):
>>
>> from
>> if (vec[i].is_open ())
>> to
>> if (vec[i].is_open () && !vec[i].h->get_close_on_exec ())
>
>Yes, this is what I had in mind, but in addition you have to
>set the handle flag to non-inherited to prevent the child from
>inheriting the handle. Then you have to set the flag back
>to normal afterwards (after the CreateProcess) to let handles
>be inherited across fork() operations.
>
>> This will solve a problem with a failing spawn()/exec() also. But one more
>> problem will arise - the os handles of these fds will be inheritted by
>> spawned child :-( Probably, it would be better to leave linearize_fd_array
>> unchanged an handle these fds in a child's delinearization code?
>
>This is what my patch currently ammounts to -- when dcrt0 starts
>up, it walks the fd table and closes any fd's that should have
>been closed at exec time. This works perfectly well with cygwin
>processes. Some other people earlier voiced concern that this
>doesn't work with non-cygwin programs which is a valid concern (but
>not my concern, since I never run non-cygwin processes :)
As Sergey has pointed out, there is no need to walk the file handle
array twice. This should be handled in the delinearize code.
-Chris
- Raw text -