Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
Yes, that is what I meant to imply. Don't wait, but look at what is currently on the table, either for ideas, or to add ideas to. Implementing something that works is a great way to influence the standard. -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Thiago Macieira Sent: Friday, November 16, 2012 6:58 PM To: development@qt-project.org Subject: Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?) On sexta-feira, 16 de novembro de 2012 23.46.32, Tony Van Eerd wrote: C++1y (ie whatever the next standard might be called) will likely have even more threading options. Including an executor model where you queue up std::functions to be run on background thread(s). But the background threading is configurable by the fact that the executor object isn't completely hidden from you (like it is with std::async(), etc). Maybe we should model something along those lines. I've used that model quite successfully in the past. I can probably find the current proposal(s) in the standards committee if anyone is interested. We can't wait for C++1y, but we should instead try and influence it by designing something nice. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
Nope. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3378.pdf -Original Message- From: Olivier Goffart [mailto:oliv...@woboq.com] Sent: Friday, November 16, 2012 6:58 PM To: Tony Van Eerd Cc: development@qt-project.org Subject: Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?) On Friday 16 November 2012 23:46:32 Tony Van Eerd wrote: C++1y (ie whatever the next standard might be called) will likely have even more threading options. Including an executor model where you queue up std::functions to be run on background thread(s). But the background threading is configurable by the fact that the executor object isn't completely hidden from you (like it is with std::async(), etc). Maybe we should model something along those lines. I've used that model quite successfully in the past. I can probably find the current proposal(s) in the standards committee if anyone is interested. Are you refering to this one? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3429.pdf -- Olivier Woboq - Qt services and support - http://woboq.com - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
On domingo, 18 de novembro de 2012 12.26.25, Sze Howe Koh wrote: On 16 November 2012 07:39, Thiago Macieira thiago.macie...@intel.com wrote: I'd like to see someone give TBB a Qt-ish API wrapper. How would the licensing work if, say, a Qt Commercial customer uses Qt-wrapped TBB, encounters a problem involving upstream TBB, and needs paid support? Would Digia need to purchase a commercial TBB licence? Replace TBB with any of these projects and ask your question again: X.org Linux distribution Windows Mac OS X Microsoft Visual Studio -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
On domingo, 18 de novembro de 2012 12.36.25, Sze Howe Koh wrote: Speaking of which, is there a reason why QFuture* classes are still in Qt Core? QFuture is meant to be created through QtConcurrent functions, if I'm not mistaken. Are still is wrong. They were moved back to QtCore, so we could reuse the names QFuture and similar for further purposes, including whatever replacements to QtConcurrent we come up with. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
On 18 November 2012 20:29, Thiago Macieira thiago.macie...@intel.com wrote: On domingo, 18 de novembro de 2012 12.26.25, Sze Howe Koh wrote: On 16 November 2012 07:39, Thiago Macieira thiago.macie...@intel.com wrote: I'd like to see someone give TBB a Qt-ish API wrapper. How would the licensing work if, say, a Qt Commercial customer uses Qt-wrapped TBB, encounters a problem involving upstream TBB, and needs paid support? Would Digia need to purchase a commercial TBB licence? Replace TBB with any of these projects and ask your question again: X.org Linux distribution Windows Mac OS X Microsoft Visual Studio Ah. I feel silly now. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
On 16 November 2012 07:39, Thiago Macieira thiago.macie...@intel.com wrote: I'd like to see someone give TBB a Qt-ish API wrapper. How would the licensing work if, say, a Qt Commercial customer uses Qt-wrapped TBB, encounters a problem involving upstream TBB, and needs paid support? Would Digia need to purchase a commercial TBB licence? Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
On 14 November 2012 19:17, Sorvig Morten morten.sor...@digia.com wrote: I think what QtConcurrent really needs is a plan. What do we want it to be? There are several options, and I'd like to offer the null option: QtConcurrent is done. The implementation is not good enough to be used as a base for further development. We should limit ourselves to fixing bugs and making small improvements where we can. This is in line with moving QtConcurrent out of Qt Core. It also has the advantage of not taking much developer time. Speaking of which, is there a reason why QFuture* classes are still in Qt Core? QFuture is meant to be created through QtConcurrent functions, if I'm not mistaken. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
On Thursday 15 November 2012 23:08:39 Sze Howe Koh wrote: Thiago also hinted that QtConcurrent development is being minimized (...we're not developing QtConcurrent anymore and shouldn't be spending any effort on this than necessary to keep it working [1]). That suggests that the dev team has reached a dead end with the code -- although the problems aren't immediately obvious to outsiders. If the quality of QtConcurrent is subpar and there's little chance of improving, then I think it's important to let Qt users know that -- through documentation and/or deprecation -- so that they don't unwittingly invest their resources in stagnant technology. The current impression I get from the official documentation is that QtConcurrent is a high-level alternative to QThread and QRunnable. QtConcurrent offers the ability to run a function in parallel, and to process a container's elements in parallel. The former can be replaced by QRunnable to an extent... but what about the latter? Are there strong use cases for parallel container processing, and is it worth salvaging that functionality? QtConcurrent is fine, but its implementation has issues. Both in the front-end (the templated code in the headers), and in the actual implementation (data structures that don't scale well, ...) Nothing that cannot really be fixed, but they would need to still re-think big parts of QtConcurrent, so that would be a huge work. Is this work worth it when there are already others libraries that offer same features (if not better) ThreadWeaver. Currently part of the KDE libraries. It has been splitted in a separate QtAddon as part of the work on KDE Frameworks. http://api.kde.org/4.9-api/kdelibs-apidocs/threadweaver/html/index.html The other option is to use the C++ standard library. C++11 contains many threading primitives. http://en.cppreference.com/w/cpp/thread -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
C++1y (ie whatever the next standard might be called) will likely have even more threading options. Including an executor model where you queue up std::functions to be run on background thread(s). But the background threading is configurable by the fact that the executor object isn't completely hidden from you (like it is with std::async(), etc). Maybe we should model something along those lines. I've used that model quite successfully in the past. I can probably find the current proposal(s) in the standards committee if anyone is interested. Tony -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Olivier Goffart Sent: Friday, November 16, 2012 1:37 PM To: development@qt-project.org Subject: Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?) On Thursday 15 November 2012 23:08:39 Sze Howe Koh wrote: Thiago also hinted that QtConcurrent development is being minimized (...we're not developing QtConcurrent anymore and shouldn't be spending any effort on this than necessary to keep it working [1]). That suggests that the dev team has reached a dead end with the code -- although the problems aren't immediately obvious to outsiders. If the quality of QtConcurrent is subpar and there's little chance of improving, then I think it's important to let Qt users know that -- through documentation and/or deprecation -- so that they don't unwittingly invest their resources in stagnant technology. The current impression I get from the official documentation is that QtConcurrent is a high-level alternative to QThread and QRunnable. QtConcurrent offers the ability to run a function in parallel, and to process a container's elements in parallel. The former can be replaced by QRunnable to an extent... but what about the latter? Are there strong use cases for parallel container processing, and is it worth salvaging that functionality? QtConcurrent is fine, but its implementation has issues. Both in the front-end (the templated code in the headers), and in the actual implementation (data structures that don't scale well, ...) Nothing that cannot really be fixed, but they would need to still re- think big parts of QtConcurrent, so that would be a huge work. Is this work worth it when there are already others libraries that offer same features (if not better) ThreadWeaver. Currently part of the KDE libraries. It has been splitted in a separate QtAddon as part of the work on KDE Frameworks. http://api.kde.org/4.9-api/kdelibs-apidocs/threadweaver/html/index.html The other option is to use the C++ standard library. C++11 contains many threading primitives. http://en.cppreference.com/w/cpp/thread -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
On sexta-feira, 16 de novembro de 2012 23.46.32, Tony Van Eerd wrote: C++1y (ie whatever the next standard might be called) will likely have even more threading options. Including an executor model where you queue up std::functions to be run on background thread(s). But the background threading is configurable by the fact that the executor object isn't completely hidden from you (like it is with std::async(), etc). Maybe we should model something along those lines. I've used that model quite successfully in the past. I can probably find the current proposal(s) in the standards committee if anyone is interested. We can't wait for C++1y, but we should instead try and influence it by designing something nice. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
On Friday 16 November 2012 23:46:32 Tony Van Eerd wrote: C++1y (ie whatever the next standard might be called) will likely have even more threading options. Including an executor model where you queue up std::functions to be run on background thread(s). But the background threading is configurable by the fact that the executor object isn't completely hidden from you (like it is with std::async(), etc). Maybe we should model something along those lines. I've used that model quite successfully in the past. I can probably find the current proposal(s) in the standards committee if anyone is interested. Are you refering to this one? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3429.pdf -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
QThread: - needs new docs (coming in 5.0) - often misused (you're doing it wrong) - results in too many dedicated threads (typically) - or threads created/destroyed too often QtConcurrent::run() - I thought this was a better alternative for one shot tasks - now it sounds like QtConcurrent is not the way to go? What should I be recommending to developers? -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Sze Howe Koh Sent: Thursday, November 15, 2012 10:09 AM To: development@qt-project.org Subject: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?) On 15 November 2012 04:31, Sune Vuorela nos...@vuorela.dk wrote: On 2012-11-14, Christian Kandeler christian.kande...@digia.com wrote: On 11/14/2012 12:17 PM, Sorvig Morten wrote: QtConcurrent is done. The implementation is not good enough to be used as a base for further development. Can you be a bit more specific? What are the general problems and why can't they be easily solved? I think it is quite limited and hard to use. I recently tried and after giving up on that, I switched a project to the ThreadWeaver library by KDE which not only made my code simpler, it also made it much easier to understand and having threading cote separated out. The ThreadWeaver library is a quite simple, but yet powerful thing built on qtcore. Thiago also hinted that QtConcurrent development is being minimized (...we're not developing QtConcurrent anymore and shouldn't be spending any effort on this than necessary to keep it working [1]). That suggests that the dev team has reached a dead end with the code -- although the problems aren't immediately obvious to outsiders. If the quality of QtConcurrent is subpar and there's little chance of improving, then I think it's important to let Qt users know that -- through documentation and/or deprecation -- so that they don't unwittingly invest their resources in stagnant technology. The current impression I get from the official documentation is that QtConcurrent is a high-level alternative to QThread and QRunnable. QtConcurrent offers the ability to run a function in parallel, and to process a container's elements in parallel. The former can be replaced by QRunnable to an extent... but what about the latter? Are there strong use cases for parallel container processing, and is it worth salvaging that functionality? Sze-Howe [1] https://codereview.qt-project.org/#change,39375 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QFuture, and QtConcurrent (was Is QtConcurrent's code generator still in use?)
On quinta-feira, 15 de novembro de 2012 21.07.09, Tony Van Eerd wrote: QThread: - needs new docs (coming in 5.0) - often misused (you're doing it wrong) - results in too many dedicated threads (typically) - or threads created/destroyed too often QtConcurrent::run() - I thought this was a better alternative for one shot tasks - now it sounds like QtConcurrent is not the way to go? What should I be recommending to developers? The solution we haven't written yet. QThread is just fine if you need a long-running thread or one that will do blocking operations. If you need to start one shot tasks, we're missing a good API to replace QtConcurrent for now. I'd like to see someone give TBB a Qt-ish API wrapper. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
