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/
