[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 #3 from Andrew Wason <rectalogic at rectalogic.com>  2011-11-14 09:06:40 PST ---
Created an attachment (id=114959)
 --> (https://bugs.webkit.org/attachment.cgi?id=114959&action=review)
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.

I'm attaching a gdb backtrace where a breakpoint was set at the end of  QCoreApplication::~QCoreApplication - after all application state has been deleted, and you can see a number of worker threads are still active (actively shutting down, but still active). This is using the sample app attached to bug 71718. Also various JS garbage collector threads can remain active.

Threads can also remain active after global static Qt internal state has been destroyed (e.g. after various Qt QGlobalStaticDeleters have destroyed global state). e.g. Q_GLOBAL_STATIC(QInternal_CallBackTable, global_callback_table) can be destroyed, and some QThread then attempts to disconnect() a signal handler and crashes because disconnect() needs global_callback_table.

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