Dear Boosters and C++ affectionados, one thing that C++ is missing amongst many others is the possibility to abort a thread in a clean fashion (so that the thread itself, i.e. the object will do the cleanup). The need for this arises virtually every time you use a background thread for doing the work (for example computations). Currently, you can have the thread check for an abort request every once in a while (bad), or you can just kill that sucker and do the cleanup in the main thread (not that nice either). A clean alternative would be if the main thread were able to "provoke" an exception in the worker thread. This "abort- request-exception" could than be caught by the worker thread. It could thereby do the entire cleanup itself (object-oriented). I added a little example below. The example is for Windows and VCPP (sorry for that). You can do the same in Linux by stopping the thread via pthread_kill(id,SIGSTOP) and then manipulating the EIP (see thread_info.h), but of course it's a bit messy due to the kernel includes, etc... Once you think about it, all you need in triggering exceptions in another thread is really an abort request. It could be either asynchronous or synchronized (mutex, with return value?). That's all you need - almost always though. The main thread handles the GUI and you almost always want the user to be able to abort operations. The smoothest way to implement this GUI-scheme is with worker threads, the downside being the lack of C++ support, currently. Different topic: ================ I read that some folks thought about the wxWidgets and the Boost (C-0x) team joining forces. I think that would be a marvelous idea! Currently the STL is quite useless. It basically serves for supporting book examples. For everything else you need either thread, network or GUI support (often all of them). As a result you have to use some library (wxWidgets, Qt). These of course all replace the STL completely - usually lacking some of those nice things the STL comes with (like exceptions). In other words: C-0x without GUI, thread and network support will just as well remain in the shadows of libraries providing that crucial functionality, sadly ignoring various accomplishments. Hold on, just cut my finger... Xo| Well, that's it anyway. Feel free to comment, as you like (as long as it doesn't relate to cutting fingers)! Blood waving, LC (myLC@gmx.net) Windows example (VCPP): ======================= #define WIN32_LEAN_AND_MEAN #include <tchar.h> #include <iostream> #include <windows.h> #include <signal.h> enum ThreadException { THREAD_ABORT_REQUEST }; DWORD threadID; unsigned long i; DWORD WINAPI ThreadFunction( LPVOID lpParam ) { try { for( ; i < 50; ++i) { std::cout << "Thead counting " << i << "..." << std::endl; Sleep( 1000 ); } std::cout << "Thead has finished counting." << std::endl; return 0; } catch( ThreadException e ) { if( e == THREAD_ABORT_REQUEST ) { std::cout << "Thread aborted." << std::endl; return 42; } else std::cerr << "Oops - unknown thread-exception" << std::endl; } catch( ... ) { std::cerr << "Unknown exception caught in thread!" << std::endl; } return 1; } __declspec( naked ) void throwAbort( void ) { throw THREAD_ABORT_REQUEST; } int _tmain( int argc, _TCHAR* argv[] ) { HANDLE threadHandle = CreateThread( 0, 0, ThreadFunction, 0, 0, &threadID ); if( !threadHandle ) { std::cerr << "Failed to create thread." << std::endl; return -1; } Sleep( 5000 ); if( SuspendThread( threadHandle ) == 0xFFFFFFFF ) { std::cerr << "Failed to suspend thread." << std::endl; return -2; } CONTEXT threadContext; threadContext.ContextFlags = CONTEXT_CONTROL; if( !GetThreadContext( threadHandle, &threadContext ) ) { std::cerr << "Failed to retrieve thread context." << std::endl; return -3; } threadContext.Eip = ( DWORD )throwAbort; if( !SetThreadContext( threadHandle, &threadContext ) ) { std::cerr << "Failed to set a new thread context." << std::endl; return -4; } if( ResumeThread( threadHandle ) == 0xFFFFFFFF ) { std::cerr << "Failed to resume thread." << std::endl; return -5; } Sleep( 3000 ); DWORD threadExitCode; if( !GetExitCodeThread( threadHandle, &threadExitCode ) ) { std::cerr << "Failed to get the thread's exit code." << std::endl; return -6; } std::cout << "The thread returned the exit code " << threadExitCode << "." << std::endl; return 0; } -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
"Ninel Evol" <myLC@gmx.de> writes:
one thing that C++ is missing amongst many others is the possibility to abort a thread in a clean fashion (so that the thread itself, i.e. the object will do the cleanup). The need for this arises virtually every time you use a background thread for doing the work (for example computations). Currently, you can have the thread check for an abort request every once in a while (bad), or you can just kill that sucker and do the cleanup in the main thread (not that nice either). A clean alternative would be if the main thread were able to "provoke" an exception in the worker thread. This "abort- request-exception" could than be caught by the worker thread. It could thereby do the entire cleanup itself (object-oriented).
The current C++0x thread library proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) includes request_cancellation(), which requests a thread cancel at the next call to cancellation_point() or one of the standard cancellation points (such as waiting on a condition variable). I intend to add this facility to Boost.thread once the move to subversion is complete.
I added a little example below. The example is for Windows and VCPP (sorry for that). You can do the same in Linux by stopping the thread via pthread_kill(id,SIGSTOP) and then manipulating the EIP (see thread_info.h), but of course it's a bit messy due to the kernel includes, etc...
This is very messy --- it's asynchronous, so will break all sorts of stuff. POSIX asynchronous thread cancellation has successfully demonstrated that it's a bad idea, except for very specific cases. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
On 05/07/07, Ninel Evol <myLC@gmx.de> wrote:
Different topic: ================ I read that some folks thought about the wxWidgets and the Boost (C-0x) team joining forces. I think that would be a marvelous idea!
I think they'd come to blows, given how reluctant wx seems to be to use any feature added to C++ in the past 17 years or so :| I don't think that's an ezaggeration, either. Have you looked at the wx developer guidelines lately? Looks like they want nothing from after the ARM: 1. Don't use C++ templates 2. Don't use C++ exceptions 3. Don't use RTTI 4. Don't use namespaces 5. Don't use STL 6. Don't declare variables inside for() 7. Don't use nested classes 8. Don't use new logical operators keywords ~ http://www.wxwidgets.org/develop/standard.htm
Currently the STL is quite useless. It basically serves for supporting book examples. For everything else you need either thread, network or GUI support (often all of them). As a result you have to use some library (wxWidgets, Qt). These of course all replace the STL completely - usually lacking some of those nice things the STL comes with (like exceptions). In other words: C-0x without GUI, thread and network support will just as well remain in the shadows of libraries providing that crucial functionality, sadly ignoring various accomplishments.
I object to the "of course". There's no reason for them all to replace the STL. In fact, the logical thing would be to build on top of the STL. Boost.Thread doesn't need to reimplement the STL, nor does Boost.ASIO, so I fail to see why other libs have to, to provide the same (or less) functionality. Last I looked, gtkmm was the closest to providing C++-style interfaces and such, so maybe there's hope. Unfortunately, http://www.omgui.org/, which was trying for a real C++ GUI lib, seems rather dead. The STL is also quite useful, all by itself. I'm using it heavily in my research. I have no use for GUIs or sockets. I tried threads, but my bottlenecks are all I/O, so they don't make a difference. I do most of my the output to console, with some OpenGL for visualization. No QT, wx, or other ancient frameworks needed, nor would they be helpful. ~ Scott
Hopefully I don't screw up the quoting. Somehow I missed the original post. On 7/5/07, Scott McMurray <me22.ca+boost@gmail.com> wrote: ...
Currently the STL is quite useless. It basically serves for supporting book examples. For everything else you need either thread, network or GUI support (often all of them). As a result you have to use some library (wxWidgets, Qt). These of course all replace the STL completely
wxWidgets replaces the STL completely?!? I work on a project that uses wx for thread and GUI support (including OpenGL graphics support), and we make *extensive* use of the STL and moderate use of several of the boost libraries. It turns out that *most* of our code actually deals with the logic of solving our particular domain problems. The GUI, network, and threads code has to actually *do* something, and we use STL and boost heavily to implement our algorithms. We have our own (crummy) in-house middleware, which I would love to replace w/ ASIO, not wxSocket et al. Once boost.Thread is more complete, we may switch that as well. I would really love to use a stable/complete GUI framework that uses modern C++. However I don't think that such a beast exists yet. Jon
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Jonathan Franklin I would really love to use a stable/complete GUI framework that uses modern C++. However I don't think that such a beast exists yet. -----End Original Message----- I would argue that gtkmm comes damn close. Now I just need to figure out if I can use it without being a slave to it's event loop. Sohail
On 7/5/07, Sohail Somani <s.somani@fincad.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Jonathan Franklin
I would really love to use a stable/complete GUI framework that uses modern C++. However I don't think that such a beast exists yet.
-----End Original Message-----
I would argue that gtkmm comes damn close.
I forgot to mention portable. The one (and only one) thing that I like about wx is that it uses the native widgets/system calls when possible. I'll have to check out gtkmm. Jon
Jonathan Franklin wrote:
On 7/5/07, Sohail Somani <s.somani@fincad.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Jonathan Franklin
I would really love to use a stable/complete GUI framework that uses modern C++. However I don't think that such a beast exists yet.
-----End Original Message-----
I would argue that gtkmm comes damn close.
I forgot to mention portable. The one (and only one) thing that I like about wx is that it uses the native wwwidgets/system calls when possible.
I'll have to check out gtkmm.
You might check out ASL's Adam and Eve. http://opensource.adobe.com/ - Michael Marcin
On 7/5/07, Michael Marcin <mmarcin@method-solutions.com> wrote:
You might check out ASL's Adam and Eve. http://opensource.adobe.com/
I saw Sean's demo at boostcon. It looks fairly interesting, though it's decoupled from any specific "widget" library (which makes sense for it's scope and purpose). I'll be playing w/ it more in the near future. I'd like a nice portable modern c++ widget library that uses native widgets/system calls under the covers. BTW, it looks like gtkmm uses mingw for Win32 support. Sadly this is a no-go for my current project, but I'll probably monkey w/ it a bit at the house. Jon
In message <fa28b9250707051129w2fec285s77c32c696a54dbcf@mail.gmail.com>, Scott McMurray <me22.ca+boost@gmail.com> writes
On 05/07/07, Ninel Evol <myLC@gmx.de> wrote:
Different topic: ================ I read that some folks thought about the wxWidgets and the Boost (C-0x) team joining forces. I think that would be a marvelous idea!
I think they'd come to blows, given how reluctant wx seems to be to use any feature added to C++ in the past 17 years or so :|
I think that this is somewhat untrue and unfair.
I don't think that's an ezaggeration, either. Have you looked at the wx developer guidelines lately? Looks like they want nothing from after the ARM: 1. Don't use C++ templates 2. Don't use C++ exceptions 3. Don't use RTTI 4. Don't use namespaces 5. Don't use STL 6. Don't declare variables inside for() 7. Don't use nested classes 8. Don't use new logical operators keywords ~ http://www.wxwidgets.org/develop/standard.htm
This doc is obviously obsolete wrt the development codebase, and the direction that it is taking. It is true that the very early design and implementation decisions (dating from pre-standard C++) have left several problems of legacy drag. Some of these have been addressed, others are being removed or mitigated. Some will be very hard to fix. Of course the project could always do with additional support, patches etc., should anyone want to contribute. ;) FWIW I have been using STL quite satisfactorily with wxWidgets for several years. [snip] -- Alec Ross, A-Train http://www.a-train.co.uk +44 (0)1689 829163 +44 (0)7710 656955 (m) A Ross Computing Services (Arcs) Ltd. 30 Cathcart Drive, Orpington, KENT, BR6 8BX UK
Alec Ross wrote:
In message <fa28b9250707051129w2fec285s77c32c696a54dbcf@mail.gmail.com>, Scott McMurray <me22.ca+boost@gmail.com> writes
Have you looked at the wx developer guidelines lately? Looks like they want nothing from after the ARM: 1. Don't use C++ templates 2. Don't use C++ exceptions 3. Don't use RTTI 4. Don't use namespaces 5. Don't use STL 6. Don't declare variables inside for() 7. Don't use nested classes 8. Don't use new logical operators keywords ~ http://www.wxwidgets.org/develop/standard.htm
I have also considered using WxWidgets and rejected it after seeing that page.
This doc is obviously obsolete wrt the development codebase, and the direction that it is taking.
Can you share a URL? I've just looked at their "Latest manual build from the CVS online" at http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin.htm and it seems to entirely follow those guidelines, with their own home-made string, list and vector classes, a "WX" prefix instead of a namespace, sentinel values to indicate errors, and so on. If this is out of date that is great news, but they are keeping their new stuff well hidden!
FWIW I have been using STL quite satisfactorily with wxWidgets for several years.
If you have a wrapper layer that converts WxString<->std::string, WxList<->std::list etc., please share it! Regards, Phil.
... In message <1183728826611@dmwebmail.belize.chezphil.org>, Phil Endecott <spam_from_boost_dev@chezphil.org> writes
Alec Ross wrote: ...
I have also considered using WxWidgets and rejected it after seeing that page.
This doc is obviously obsolete wrt the development codebase, and the direction that it is taking.
Can you share a URL? Phil, if it comes to it, I might look up one, and post it. But Vadim Zeitlin has a post in train that has not yet made it to this list. He would be far better placed than I to answer this kind of question in detail if that is needed.
I've just looked at their "Latest manual build from the CVS online" at http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin.htm and it seems to entirely follow those guidelines, with their own home-made string, list and vector classes, a "WX" prefix instead of a namespace, sentinel values to indicate errors, and so on. If this is out of date that is great news, but they are keeping their new stuff well hidden!
In brief, my take on this is that wxWidgets _can_ be used with "modern" C++ code and idioms. And the core of wxWidgets itself is being modernised.
FWIW I have been using STL quite satisfactorily with wxWidgets for several years.
If you have a wrapper layer that converts WxString<->std::string, WxList<->std::list etc., please share it!
Vadim, again. (?) (Though I could post URLs to wxWidgets posts.) BTW, I'm in doubt as to just how far OT this thread is going wrt Boost. I've continued here since it was raised here, and I think it worth noting, inter alia, that wxW can be used with contemporary C++ idioms and code such as Boost. But I'm inclined to shut up from now on. If your specific questions seem to go without satisfactory resolution here, Phil, I'll try to answer them off list. Regards, Alec -- Alec Ross
On Fri, 6 Jul 2007 09:17:37 +0100 Alec Ross <alec@arlross.demon.co.uk> wrote: AR> In message <fa28b9250707051129w2fec285s77c32c696a54dbcf@mail.gmail.com>, AR> Scott McMurray <me22.ca+boost@gmail.com> writes AR> >On 05/07/07, Ninel Evol <myLC@gmx.de> wrote: AR> >> Different topic: AR> >> ================ AR> >> I read that some folks thought about the wxWidgets and the AR> >> Boost (C-0x) team joining forces. AR> >> I think that would be a marvelous idea! AR> >> AR> >I think they'd come to blows, given how reluctant wx seems to be to AR> >use any feature added to C++ in the past 17 years or so :| AR> > AR> I think that this is somewhat untrue and unfair. I'd say that it is out of date. We don't impose any requirements not to use some C++ features any more in (upcoming) wxWidgets 3. But it's true that we have to make sure that our code builds on a lot of platforms, some of them with rather bad C++/STL support (for instance Windows CE or Symbian still don't have the latter at all) and this still imposes some restrictions in practice. Anyhow, we'd definitely be interested in collaborating with Boost developers as much as possible. In particular, the ideas/feedback about the new, better API for what we call wxTNG would be very welcome. Please post to wx-dev if you're interested in discussing this further. Regards, VZ
Vadim Zeitlin wrote:
I'd say that it is out of date. We don't impose any requirements not to use some C++ features any more in (upcoming) wxWidgets 3. But it's true that we have to make sure that our code builds on a lot of platforms, some of them with rather bad C++/STL support (for instance Windows CE or Symbian still don't have the latter at all) and this still imposes some restrictions in practice.
Even further OT but... Windows CE and Symbian do have STL. At least recent versions. MSVC 2005 standard and above ship with a Windows CE STL and Symbian now comes with OpenC + STLPort. - Michael Marcin
On Friday 06 July 2007 15:38:17 Vadim Zeitlin wrote:
[...] it's true that we have to make sure that our code builds on a lot of platforms, some of them with rather bad C++/STL support (for instance Windows CE or Symbian still don't have the latter at all) and this still imposes some restrictions in practice.
Not true anymore! ;) I know that STLport works pretty well for CE4 and CE5, since I'm using and maintaining it there. The port to CE3 has not been tested by me, but I think it is still maintained. Some porting work towards Symbian has also been done, but I'm not sure how far this has been integrated into mainstream releases. cheers and happy hacking! Uli
participants (10)
-
Alec Ross -
Anthony Williams -
Jonathan Franklin -
Michael Marcin -
Ninel Evol -
Phil Endecott -
Scott McMurray -
Sohail Somani -
Ulrich Eckhardt -
Vadim Zeitlin