This is the mail archive of the cygwin 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: Questions on patching

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 and how-programming.texinfo that
>refer the reader to this test program.

We don't need a "contrib" directory.  The whole cygwin distribution is

>>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

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

Or, as you have seen, you can call sigwait() in its own thread.  That
could be slightly racy, though.


Unsubscribe info:
Problem reports:

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