Re: [Development] Timeout for QFuture::waitForFinished()

[Lorenz Haas]

Thanks for all your input. I'll have a look at QUIP-6 and a closer
look at the implementation.

2018-07-10 23:55 GMT+02:00 Thiago Macieira :
> On Tuesday, 10 July 2018 12:31:30 PDT Lorenz Haas wrote:
>> So I wonder if there is any technical/intentional reason why there is
>> no timeout parameter?
>
> There may be. The problem with timed thread waits is that you need to wake up
> and release state at the same time the signaller is trying to use that
> content.
>
> I'm not saying this is an actual issue here as I don't know the code. But
> there could be such an issue.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Timeout for QFuture::waitForFinished()

[Lorenz Haas]

Hi André,

you are right. My statement was not precise enough: Adding a parameter
to the existing function would be BiC, adding an overload "void
QFutureWatcher::waitForFinished(int timeout);" is BC but would be SiC
because it makes function pointers ambiguous - at least I think so.
About the latter I am also not sure, if that would be a problem since
I am not familiar with the exact promises Qt makes about SC.

BR
Lorenz

2018-07-10 21:46 GMT+02:00 André Hartmann :
> Hi Lorenz,
>
> I can only reply to the second half of your request.
>
>> Follow-up question if a timeout could be added: AFAIK adding an new
>> parameter to waitForFinished() or adding an overload is BiC.
>
>
> That's only true if you *change* the existing method. Adding a new
> overload while keeping the existing method *is possible*. So if you have:
>
>   void QFutureWatcher::waitForFinished();
>
> you can add in Qt 5:
>
>   void QFutureWatcher::waitForFinished(int timeout);
>
> and merge both in Qt 6:
>
>   void QFutureWatcher::waitForFinished(int timeout = 3); // or -1
>
> Regards,
> André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Timeout for QFuture::waitForFinished()

[Lorenz Haas]

Hi,

today I wished QFuture::waitForFinished() had a timeout parameter.
After a brief look waitForFinished() uses a QWaitCondition::wait()
internally, which already provides an optional timeout parameter.

So I wonder if there is any technical/intentional reason why there is
no timeout parameter?

Follow-up question if a timeout could be added: AFAIK adding an new
parameter to waitForFinished() or adding an overload is BiC. Thus
would a timeout parameter have to wait for Qt6 or could it be realized
for Qt 5 e.g. with a behavior like m_cancelOnWait of
QFutureSynchronizer?

Thanks
Lorenz
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Threads and the SQL Module

[Lorenz Haas]

Hi,

AFAIS it does not matter if sqlite is thread safe or not. The problem is
that QSQLiteDriver itself is not thread safe. For example if two threads
call beginTransaction() on the same driver and the "COMMIT" fails, both
threads will call QSqlDriver::setLastError() which does "d->error =
error;". And here is the first problem.

I am not an expert with QSqlQuery, but since it uses the driver, I bet,
you'll also find UB and races there.

Cheers
Lorenz

Am 15.02.2017 um 13:37 schrieb Łukasz Korbel:
> According to
> http://doc.qt.io/qt-5/threads-modules.html#threads-and-the-sql-module
> database connection should be used within one thread *only*.
> 
> I have checked SQLite driver and according to
> https://www.sqlite.org/threadsafe.html it supports multithreading by
> default. And it seems that Qt implementation does not restrict it
> (http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp#n645).
> Code I'm working on is creating QSqlQuery for the same connection in
> different threads and it works.
> 
> I understand it doesn't mean Qt want or need to support such use case
> but maybe documentation
> can be slightly more accurate? Right now it implies that database
> connection can never be used from different threads but it seem it
> depends more on particular driver/3rdparty lib.
> 
> 
> *Łukasz Korbel *
> Senior Software Developer
> Email:lkor...@milosolutions.com
> Skype:lukasz_korbel
> *Milo Solutions*
> www.milosolutions.com  | Facebook
>  | Twitter
> 
> Disclaimer: This e-mail and any attachments contain information that may
> be privileged or confidential and is the property of Milo Solutions. If
> you are not the intended recipient, please notify me immediately by
> replying to this e-mail, and then delete it. Any unauthorised
> dissemination, distribution, copying or use of this communication is
> strictly prohibited. The contents of an attachment to this e-mail may
> contain software viruses, which could damage your own computer system.
> Although this e-mail and any files attached to it may have been checked
> with virus detection software before transmission you should carry out
> your own virus checks before opening the attachment. No liability can be
> accepted for any damage which you may sustain as a result of software
> viruses.
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format config file.

[Lorenz Haas]

Hi,

> The style disabled any re-wraping of the comments, because the qdoc rules are
> not encoded in clang-format. So comments will not be touched.

just for the record: clang-format can exclude specific comment types
from re-wrapping. Thus if you/we do not mind a "either re-wrap all
comments or leave them all as they are" rule, CommentPragmas could be
used, e.g.:

CommentPragmas: '^!|^:|^=|^~'

Cheers
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Is QFutureInterface internal like the other d-pointer classes?

[Lorenz Haas]

2015-07-23 13:20 GMT+02:00 Marc Mutz :
> It's undocumented, and considered private, but since it's a template and thus
> must be visible, it effectively is public API and falls under the same
> restrictions for changes as public API. IOW: it cannot change (incompatibly)
> until Qt 6.
>
> If you're fine with that, go ahead and use it in your code.

Thanks for the clarification.

Are there any plans to make QFuture/QFutureInterface (completely)
public in Qt 6 as a Qt counterpart to std::future/std::promise?

Lorenz
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Is QFutureInterface internal like the other d-pointer classes?

[Lorenz Haas]

Hi,

most - if not all - d-pointer/private implementation files are
*internal* and should not be used in a "normal" project - meaning a
project that just uses Qt. These files/classes are clearly marked by

//
//  W A R N I N G
//  -
//
// This file is not part of the Qt API.  It exists purely as an
// implementation detail.  This header file may change from version to
// version without notice, or even be removed.
//
// We mean it.
//

What about QFutureInterface? Is it safe to use it in a normal project
or can it be changed at any time like the other internal classes?

qfutureinterface.h/.cpp does not have the cited warning.
QFutureInterfaceBase is furthermore exported, QFutureInterface not.
Why? I also do not understand the comment in qfuture.h:

public: // Warning: the d pointer is not documented and is considered private.
mutable QFutureInterface d;

Okay, it is not documented, but I can read the source code, or is all
not documented Qt code considered *internal*? Hope not. The comment
also mentions "private". This is only related to the access
specification, is it? Or does private here also means *internal*?

Thanks
Lorenz
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector now has rvalue push_back (was: Re: HEADS UP: potential trouble from a recent QVector change)

[Lorenz Haas]

2015-07-20 21:26 GMT+02:00 Thiago Macieira :

> Aside from the variadic and the templateness, what's the difference?
>
> The templateness changes how a type different than the vector's type gets
> constructed (it might undergo a conversion first). But assuming I am
> pushing
> back a T, is there any reason I'd want emplace_back? Or vice-versa?
>

Just a side node: Scott Meyer targets push_back/emplace_back in his new
book (item 42)  and gave a talk about it:
https://www.youtube.com/watch?v=smqT9Io_bKo. Due to a tremendous lack of
deeper knowledge no further information from my side :)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development