[Interest] Qthread from QFuture?

[Scott Bloom]

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.macieira at intel.com> 
Sent: Tuesday, January 4, 2022 4:28 PM
To: interest at qt-project.org
Cc: Scott Bloom <scott at 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