Skip to content

C
core
Dal (branch)/etiket değiştir
  1. 23 May, 2012 3 kayıt (commit)
    • Stephan Bergmann's avatar
      Better fix for ThreadPool/ORequestThread life cycle · 2fa2660b
      Stephan Bergmann yazdı 
      This is a follow up to d015384e "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:

* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.

That has been addressed by giving Bridge::dispose new semantics:  It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined.  (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)

* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.

That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock.  (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)

* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.

That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.

Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
      2fa2660b
    • Kohei Yoshida's avatar
      Receive the file open command in Calc in order to pass doc service name. · 124c020f
      Kohei Yoshida yazdı 
      This way the type detection is guaranteed to receive the document service
name whenever a file is being opened from Calc.

Change-Id: I0eec06d4ca1f3f30bcbc5685af73392276990d69
      124c020f
    • Kohei Yoshida's avatar
      Add mechanism to pass doc service name to the descriptor when opening a file. · e58eb031
      Kohei Yoshida yazdı 
      This info will be used during type detection for more clever filter
selection.

Change-Id: I66a52ff6f425e97884afd1c85831c11381fb695d
      e58eb031
  3. 22 May, 2012 37 kayıt (commit)