[Webkit-unassigned] [Bug 72155] Replace Qt QThread threading back-end with pthread/Win32 threading back-ends

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=72155





--- Comment #4 from Simon Hausmann <hausmann at webkit.org>  2011-11-16 03:00:55 PST ---
(In reply to comment #3)
> Created an attachment (id=114959)
 --> (https://bugs.webkit.org/attachment.cgi?id=114959&action=review) [details]
> gdb backtrace showing WebWorker threads active after QCoreApplication destruction
> 
> (In reply to comment #2)
> > 
> > I like the idea of more code sharing and while introducing the pthreads dependency on windows is
> > painful, I clearly see benefits.
> 
> I don't think this introduces a pthreads dependency on windows, ThreadingWin.cpp uses native Win32 threading APIs.
> 
> > Could you elaborate a bit how it is possible that web workers can outlive the QApplication instance?
> > It doesn't sound like something "intentional" to me, but I might easily be missing something :)
> 
> There is nothing that waits for the worker threads to finish - so there is a race condition. The WorkerThread event loops are quit, but they can still be busy tearing down state after QApplication has been destroyed.

Hm, but shouldn't there be something that waits for them?

I mean... is it really true that for example when running a worker script in say Chrome it can actually outlive the life time of the "tab" or even window that started it? I find that difficult to believe, especially given that without being able to post a message back, why should it be left running? :)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.