| Summary: | FileManagerListJob::m_listQueue : needs mutex protection? | ||
|---|---|---|---|
| Product: | [Developer tools] kdevplatform | Reporter: | RJVB <rjvbertin> |
| Component: | project | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | task | ||
| Priority: | NOR | ||
| Version First Reported In: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | All | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
RJVB
2018-03-14 15:42:17 UTC
where is it accessed from a background thread? that should not happen. the only background-thread activity to my knowledge happens within the QtConcurrent::run section, which then dispatches its results through QMetaObject::invokeMethod, which will get handled by the main thread again. Ahem, I should have 2nd-guessed myself and dump thread IDs from within FMLJ methods :( I always thought the list job itself runs on a background thread and thus that FileManagerListJob::startNextJob() is called on that thread when the class sends itself the nextJob signal. It inherits KJob after all, and is controlled via asynchronous methods (if that's the correct term). So exactly what is running on a background thread here, or should I say, why does the class inherit KJob if the only background activity is in the QtConcurrent::run() call? (BTW, the invokeMethod() call is made after the call into QtConcurrent; I agree it targets the main thread.) parallelism doesn't necessarily require threads, KJob is event driven. And yes, the invokeMethod isn't done after the QtConcurrent::run, but more importantly, it's done from _within_ the functor run in the background. Anyhow, closing this report, it's clearly invalid. Well, my bad, sorry for the noise. |