This is the mail archive of the
mailing list for the Cygwin project.
Re: Protect handle issue-ettes
On Sun, Jul 14, 2002 at 07:29:06PM +0100, Conrad Scott wrote:
>"Christopher Faylor" <firstname.lastname@example.org> wrote:
>> Huh? The code in dll_crt0_1 is supposed to be called
>> on a fork or an exec. That's why I renamed it to
>> As far as I can tell it *is* called on a fork.
>> strace confirms that.
>Sorry Chris, I've obviously misunderstood something then. I tried
>calling setclexec() for one of the handles that was causing
>trouble (the title_mutex) but it didn't change anything, while
>removing the ProtectHandle call for it removed a whole lot of
>warnings (as far as I can remember from this morning).
Did you look at the changes to add_handle? A CVS diff might be
instructive. Here are the bulk of the changes:
The default case for a handle is not to be inherited. That hasn't
changed. Calling setclexec on most of the handles that cygwin uses for
its own purposes should be a no-op -- this hasn't changed either.
What has changed is the use of the new macro ProtecHandle*INH. This is
now used on those rare handles that are supposed to be inherited.
>One thing that is confusing me is that if you call fcntl() to set
>the close-on-exec flag for a file descriptor, this ends up calling
>setclexec(). But if the clexec flag is honoured on fork (as well
>as exec) how can this be right?
It shouldn't matter. The clexec is basically a "This handle is not
inherited" flag. It's possible that the logic is wrong and an fd with
clexec set will disappear from the debug list of handles inappropriately
but that's not going to cause collisions AFAICT.
Actually, on checking this, it seems obvious that I either never
completed the clexec for fds stuff or wiped it out for some reason. So,
a normal fd doesn't show up on the list of protected handles anyway.
I've removed the setclexec code from the DLL.
>I'll go have another look at the code sometime soon and write some
>test programs, since the volume of warnings in the cygserver
>branch is a little distracting.
I just tried it with a branch DLL and a branch cygserver. Still no
warnings. I didn't see any warnings.
A branch server and trunk DLL just errored out.
It almost sounds like you are not running with the most recent sources.