This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Questions on patching dcrt0.cc
On Thu, May 26, 2005 at 11:20:35AM -0700, Max Kaehn wrote:
>On Thu, 2005-05-26 at 11:00, Christopher Faylor wrote:
>>Rather than talking about "MSVC code" being "acceptable", please just
>>provide a specific indication of *what* you are trying to do. Where do
>>you want to put this code? Look at the directories available in winsup
>>and tell us where you want to put this.
>
>I want to make it as easy as possible for cygwin developers who are
>working with the cygwin initialization code that they don't break this
>functionality. It seems to me that a subdirectory of winsup/testsuite
>would be good for this. You remarked in semi-private E-mail that "we
>won't be putting any MSVC source in the winsup directory", and I want
>to respect the policies of the cygwin project, so I'm asking where you
>would like a program of this nature. A new subdirectory of "contrib"
>might also be appropriate. Wherever it goes, I want to put comments in
>the patches I will submit for dcrt0.cc and how-programming.texinfo that
>refer the reader to this test program.
We don't need a "contrib" directory. The whole cygwin distribution is
contributed.
>>As I mentioned in semi-private email, the fact that you can get cygwin
>>working by dynamic linking doesn't mean that it can necessarily be used
>>by proprietary programs if by "proprietary" you mean "non open source".
>
>As I understand it, this clause in the cygwin license:
To reiterate and clarify: providing the ability to do dynamic linking
does not necessarily affect the existing cygwin DLL licensing.
>>? Why wouldn't signal handling just work? A program would have to
>>call "GetProcAddress" to retrieve the address of any signal function
>>that it wanted to use but it should just work if all of the appropriate
>>stuff is initialized in cygwin.
>
>As far as I can tell, the main thread needs to be running an
>interruptible cygwin function in order to receive signals from cygwin.
>This works fine if your main routine is waiting on sleep() or
>pthread_cond_timedwait(), but not if it's busy in the Microsoft
>libraries. Spawning an additional thread to call sigwait() will
>minimize the cost of integration of this functionality into existing
>programs.
Right. If the program is blocking then it should be running a cygwin
function and the stack must be set up to be able to handle this. If the
main thread is blocking in a non-cygwin function then it won't be
interruptible. If the main thread is not blocking and is just running
normal user (i.e., not system-DLL) code then it will be interrupted
immediately.
Or, as you have seen, you can call sigwait() in its own thread. That
could be slightly racy, though.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/