I appreciate the information. However, I don’t understand why a QFuture
created by QtConcurrent::run, if it can tell isRunning, why it cant return the
QThread its using?
Unless there is simply no QThread, and its using all OS calls (which could make
sense).
::exit( 0 ) would be too abrupt, but possible. No need for that. Honestly,
its mostly when running in the debugger and it "hangs" on exit.
Other questions answered inline below
-----Original Message-----
From: Thiago Macieira <thiago.macie...@intel.com>
Sent: Tuesday, January 4, 2022 4:28 PM
To: interest@qt-project.org
Cc: Scott Bloom <sc...@towel42.com>
Subject: Re: [Interest] Qthread from QFuture?
On Tuesday, 4 January 2022 16:07:05 -03 Scott Bloom wrote:
> Is there anyway to get (if it even exists) a QThread from a
> QFuture/QFutureWatcher?
You can't get it because a thread will not have been assigned until the job
starts. The thread that ends up running your job may be any of the threads in
the pool.
And this is assuming we were talking about QtConcurrent::run. If you meant an
operation on a container, you will have more than one thread assigned to the
job.
> The main issue, and I know this going to sound horrible, I would like to
> kill/terminate the thread, I know its safe 😊 (famous last words)..
Yeah. So do everyone a favour and refactor. This is not a valid use-case, for
multiple reasons. If you REALLY need to do it, here's the call I recommend you
do to stop that job:
::exit(0);
I'm not kidding. This is also the hint to solving your problem.
> Here is what im doing, maybe someone has a better solution (Im sure of it).
>
> I have a Qlineedit entry that takes a path. Often, this path is network
> based, and very often over VPN, meaning its NOT always connected.
Do you mean NFS? Or Windows SMB? Or do you mean a FUSE-based network mount on
Unix?
=================
From windows, SMB
From Linux, Ive seen it with NFS connections as well as SMB
===============
> On the text changing, the window determines if the path is valid
> (QFileInfo::exists, isDir, isExecutable for directories, some are files).
> Unfortunately, if the VPN is not connected, it can take up to 30 seconds
> for the OS to return “no it doesn’t exist”. (Windows is the primary OS,
> but I have seen the same on Linux)
> There is no way to interrupt the single class to the OS, its frozen in the
> thread (better than also freezing the GUI). But If I could ask the
> watcher, give me your QThread and let me terminate it, it would fix the
> issue.
On WIndows, exit() first kills all threads aside from the one that called
exit() so you don't have to wait. In fact, you MUSTN'T wait, otherwise you'll
deadlock. You must intentionally leak any resources that depend on threads.
Stop using QtConcurrent for this. If you must kill a thread, use QThread
itself or, better yet, the low-level API for your OS. Or use QProcess.
===========
Its such a nice simple interface for launching a background thread and
asynchronously being notified when it finishes 😊
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
