Re: [CMake] Interrupt problems in cmake-gui
In addition the issue is with the Qt base GUI and Qt has all the APIs necessary to accomplish what you need. There is no need for boost to fix the problem. - Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio Sent from my mobile device. Please excuse the shortness of the reply. On Jan 6, 2012, at 1:12, Michael Hertling mhertl...@online.de wrote: On 12/31/2011 02:10 AM, Robert Dailey wrote: I'd like to introduce boost into CMake for this. Whenever I've advocated CMake as build system, one of the strongest selling points has been its self-sufficiency, i.e. the fact that it does not have any external dependencies except for a C++ environment. IMO, each further dependency on external packages - be it Boost, be it Qt or what ever - would compromise CMake's chances to be preferred to other build systems. For this reason, I'd support Bill's position and recommend to be particularly conservative w.r.t. the introduction of additional dependencies into the CMake executable. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interrupt problems in cmake-gui
On 12/31/2011 02:10 AM, Robert Dailey wrote: I'd like to introduce boost into CMake for this. Whenever I've advocated CMake as build system, one of the strongest selling points has been its self-sufficiency, i.e. the fact that it does not have any external dependencies except for a C++ environment. IMO, each further dependency on external packages - be it Boost, be it Qt or what ever - would compromise CMake's chances to be preferred to other build systems. For this reason, I'd support Bill's position and recommend to be particularly conservative w.r.t. the introduction of additional dependencies into the CMake executable. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Interrupt problems in cmake-gui
I have a foreach/while loop that checks if files exist. The files it is checking are on a Windows network share. So, each check takes a while. Sometimes after I click Configure in cmake-gui.exe, I want to click Stop during this check. However, the stop does not seem to interrupt the loop. I know this because let's say the whole loop takes 20 seconds to complete. If I let the loop run without clicking stop, it takes 20 seconds. If I click stop at about 10 seconds, then 10 seconds later it stops. In other words, clicking stop does not take affect until 20 seconds have passed anyway. So it obviously isn't stopping it. My loops basically look like this: while() foreach() if( EXISTS ) endif() endforeach() endwhile() If I am checking 20 files, each check takes about 1 second to equal a total time of 20 seconds. So, at most, after clicking stop, there should be a 1 second wait time. Can anyone verify that while/foreach loops can or cannot be interrupted by cmake-gui? - Robert Dailey -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interrupt problems in cmake-gui
I found the problem in code and currently have a fix. However, the code change requires some thread synchronization. Does anyone know if there is a reader/writer lock object in the CMake source code? - Robert Dailey On Fri, Dec 30, 2011 at 9:58 AM, Robert Dailey rcdai...@gmail.com wrote: I have a foreach/while loop that checks if files exist. The files it is checking are on a Windows network share. So, each check takes a while. Sometimes after I click Configure in cmake-gui.exe, I want to click Stop during this check. However, the stop does not seem to interrupt the loop. I know this because let's say the whole loop takes 20 seconds to complete. If I let the loop run without clicking stop, it takes 20 seconds. If I click stop at about 10 seconds, then 10 seconds later it stops. In other words, clicking stop does not take affect until 20 seconds have passed anyway. So it obviously isn't stopping it. My loops basically look like this: while() foreach() if( EXISTS ) endif() endforeach() endwhile() If I am checking 20 files, each check takes about 1 second to equal a total time of 20 seconds. So, at most, after clicking stop, there should be a 1 second wait time. Can anyone verify that while/foreach loops can or cannot be interrupted by cmake-gui? - Robert Dailey -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interrupt problems in cmake-gui
There isn't a lock. Synchronization is done by threads having event loops and calling Qt slots in a queued fashion (like posting messages to the other event queue). I imagine you just need to add another place where the interrupt is checked and gracefully return (which should take you back to the event loop). Clint - Reply message - From: Robert Dailey rcdai...@gmail.com Date: Fri, Dec 30, 2011 10:07 am Subject: [CMake] Interrupt problems in cmake-gui To: CMake ML cmake@cmake.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interrupt problems in cmake-gui
I don't know much about Qt, but what I do know is the fix involves using a direct connection. In CMakeSetupDialog::doInterrupt(), I changed the invokeMethod() command to use Qt::DirectConnection. However, this solution is not thread safe, hence why I asked about synchronization. I could implement a multiple-reader/single-writer lock, but I'd much rather use Boost.Thread, but this would require introducing the boost library into the cmake build. The following methods in cmSystemTools need to be made thread-safe (using a combination of read locks writer locks). Qt has a reader/writer lock but I can't use this in cmSystemTools, since it will require cmake.exe to depend on Qt, which doesn't make much sense. GetErrorOccuredFlag() SetFatalErrorOccured() GetFatalErrorOccured() ResetErrorOccuredFlag() I was thinking of turning cmSystemTools into a singleton (you would have a static instance() method and access members through that) and using inheritance to implement a thread-safe variant of this class. I could create thread-safe overrides the above methods and utilize polymorphism to access the thread safe version in cmake-gui, whereas cmake.exe would not use it, since by itself it does not need it. I'd like to introduce boost into CMake for this. If you can find a better implementation that'd be great, I haven't been working with the CMake code base as long as you guys have, so you probably know an easier fix. The main issue is that the blocking functions (such as while, foreach) do not return control to Qt until after they are done executing, and the only way to reliably interrupt them is by setting the fatal error flag. It requires no additional interrupt logic. These are the findings of my investigation and debugging. Thanks in advance for your input. - Robert Dailey On Fri, Dec 30, 2011 at 12:53 PM, clin...@elemtech.com clin...@elemtech.com wrote: There isn't a lock. Synchronization is done by threads having event loops and calling Qt slots in a queued fashion (like posting messages to the other event queue). I imagine you just need to add another place where the interrupt is checked and gracefully return (which should take you back to the event loop). Clint - Reply message - From: Robert Dailey rcdai...@gmail.com Date: Fri, Dec 30, 2011 10:07 am Subject: [CMake] Interrupt problems in cmake-gui To: CMake ML cmake@cmake.org I found the problem in code and currently have a fix. However, the code change requires some thread synchronization. Does anyone know if there is a reader/writer lock object in the CMake source code? - Robert Dailey On Fri, Dec 30, 2011 at 9:58 AM, Robert Dailey rcdai...@gmail.com wrote: I have a foreach/while loop that checks if files exist. The files it is checking are on a Windows network share. So, each check takes a while. Sometimes after I click Configure in cmake-gui.exe, I want to click Stop during this check. However, the stop does not seem to interrupt the loop. I know this because let's say the whole loop takes 20 seconds to complete. If I let the loop run without clicking stop, it takes 20 seconds. If I click stop at about 10 seconds, then 10 seconds later it stops. In other words, clicking stop does not take affect until 20 seconds have passed anyway. So it obviously isn't stopping it. My loops basically look like this: while() foreach() if( EXISTS ) endif() endforeach() endwhile() If I am checking 20 files, each check takes about 1 second to equal a total time of 20 seconds. So, at most, after clicking stop, there should be a 1 second wait time. Can anyone verify that while/foreach loops can or cannot be interrupted by cmake-gui? - Robert Dailey -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interrupt problems in cmake-gui
On 12/30/2011 8:10 PM, Robert Dailey wrote: I'd like to introduce boost into CMake for this. No way... :) -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interrupt problems in cmake-gui
Yeah it does look like synchronization is needed to fix this. The current interrupt functionality depends on message output or progress reporting to actually process the interrupt on the worker thread, which isn't good enough. I'm not sure if you've considered this, but it seems simpler to add an interrupt callback in cmSystemTools, much like the callbacks work for stdout/stderr. Then cmake-gui could register an interrupt callback and coordinate that with the button click. The synchronization of a simple flag can then be handled within cmake-gui using QAtomicInt. Clint On Dec 30, 2011, at 6:10 PM, Robert Dailey wrote: I don't know much about Qt, but what I do know is the fix involves using a direct connection. In CMakeSetupDialog::doInterrupt(), I changed the invokeMethod() command to use Qt::DirectConnection. However, this solution is not thread safe, hence why I asked about synchronization. I could implement a multiple-reader/single-writer lock, but I'd much rather use Boost.Thread, but this would require introducing the boost library into the cmake build. The following methods in cmSystemTools need to be made thread-safe (using a combination of read locks writer locks). Qt has a reader/writer lock but I can't use this in cmSystemTools, since it will require cmake.exe to depend on Qt, which doesn't make much sense. GetErrorOccuredFlag() SetFatalErrorOccured() GetFatalErrorOccured() ResetErrorOccuredFlag() I was thinking of turning cmSystemTools into a singleton (you would have a static instance() method and access members through that) and using inheritance to implement a thread-safe variant of this class. I could create thread-safe overrides the above methods and utilize polymorphism to access the thread safe version in cmake-gui, whereas cmake.exe would not use it, since by itself it does not need it. I'd like to introduce boost into CMake for this. If you can find a better implementation that'd be great, I haven't been working with the CMake code base as long as you guys have, so you probably know an easier fix. The main issue is that the blocking functions (such as while, foreach) do not return control to Qt until after they are done executing, and the only way to reliably interrupt them is by setting the fatal error flag. It requires no additional interrupt logic. These are the findings of my investigation and debugging. Thanks in advance for your input. - Robert Dailey On Fri, Dec 30, 2011 at 12:53 PM, clin...@elemtech.com clin...@elemtech.com wrote: There isn't a lock. Synchronization is done by threads having event loops and calling Qt slots in a queued fashion (like posting messages to the other event queue). I imagine you just need to add another place where the interrupt is checked and gracefully return (which should take you back to the event loop). Clint - Reply message - From: Robert Dailey rcdai...@gmail.com Date: Fri, Dec 30, 2011 10:07 am Subject: [CMake] Interrupt problems in cmake-gui To: CMake ML cmake@cmake.org I found the problem in code and currently have a fix. However, the code change requires some thread synchronization. Does anyone know if there is a reader/writer lock object in the CMake source code? - Robert Dailey On Fri, Dec 30, 2011 at 9:58 AM, Robert Dailey rcdai...@gmail.com wrote: I have a foreach/while loop that checks if files exist. The files it is checking are on a Windows network share. So, each check takes a while. Sometimes after I click Configure in cmake-gui.exe, I want to click Stop during this check. However, the stop does not seem to interrupt the loop. I know this because let's say the whole loop takes 20 seconds to complete. If I let the loop run without clicking stop, it takes 20 seconds. If I click stop at about 10 seconds, then 10 seconds later it stops. In other words, clicking stop does not take affect until 20 seconds have passed anyway. So it obviously isn't stopping it. My loops basically look like this: while() foreach() if( EXISTS ) endif() endforeach() endwhile() If I am checking 20 files, each check takes about 1 second to equal a total time of 20 seconds. So, at most, after clicking stop, there should be a 1 second wait time. Can anyone verify that while/foreach loops can or cannot be interrupted by cmake-gui? - Robert Dailey -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
