Skip to content

C
core
Dal (branch)/etiket değiştir
  1. 06 May, 2013 3 kayıt (commit)
  3. 07 Nis, 2013 1 kayıt (commit)
    • Luboš Luňák's avatar
      mass removal of rtl:: prefixes for O(U)String* · 1946794a
      Luboš Luňák yazdı 
      Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).

Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
      1946794a
  5. 19 Mar, 2013 3 kayıt (commit)
  7. 01 Şub, 2013 1 kayıt (commit)
  9. 19 Ara, 2012 4 kayıt (commit)
    • Stephan Bergmann's avatar
      API CHANGE: Remove support for uno executable's -ro/-rw arguments · 5a1d5113
      Stephan Bergmann yazdı 
      ...and instead require users to specify URE_MORE_SERVICES/TYPES (resp.
UNO_SERVICES/TYPES for invocations from within the build) bootstrap variables.

This removes usage of deprecated bootstrap_InitialComponentContext from the
uno executable's code.

Change-Id: I9af626f47a94c3bea1fb0d3c3efbab54f8db9e40
      5a1d5113
    • Stephan Bergmann's avatar
      Fix for making absolute the registry arguments of the uno executable · e43fd91b
      Stephan Bergmann yazdı 
      a25bec0c "Properly absolutize all registry
arguments of uno executable" at least broke testtools/CustomTarget_uno_test.mk
on Windows, where some -ro argument system path starting with a drive letter
("C:/...") is passed in, which rtl::Uri::convertRelToAbs mis-interprets as a
URI with scheme "c".

Switching to osl::FileBase::getAbsoluteFileURL started to break Linux, where
osl_getAbsoluteFileURL for whatever reason calls
osl::FileBase::getSystemPathFromFileURL, which in turn for whetever reason
rejects relative input that starts with "/".  The easiest fix that appears not
to break anything else appears to be the workaround now added to
osl_getAbsoluteFileURL.

Change-Id: If03e7136ecc2c26a8f31e591257b1886f3ab129b
      e43fd91b
    • Stephan Bergmann's avatar
      Missing "_" in prefixes · e87e9ab4
      Stephan Bergmann yazdı 
      ...likely gone unnoticed until now as that nested if is not normally taken, the
createInstanceWithContext call at the top shall normally succeed.

Change-Id: Iabc917473cf6902cb2afc21b735411d8136278fb
      e87e9ab4
    • Stephan Bergmann's avatar
      Remove obsolete regsingleton · 9780454a
      Stephan Bergmann yazdı 
      Change-Id: Ia8b83e69401dccd37c3350e381093af1dd5b17af
      9780454a
  11. 18 Ara, 2012 3 kayıt (commit)
  13. 02 Eki, 2012 2 kayıt (commit)
  15. 16 Tem, 2012 1 kayıt (commit)
  17. 14 Haz, 2012 1 kayıt (commit)
  19. 23 May, 2012 1 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
  21. 11 Nis, 2012 1 kayıt (commit)
  23. 06 Nis, 2012 1 kayıt (commit)
  25. 21 Mar, 2012 1 kayıt (commit)
  27. 16 Şub, 2012 2 kayıt (commit)
  29. 26 Ock, 2012 1 kayıt (commit)
  31. 20 Ock, 2012 1 kayıt (commit)
  33. 17 Ara, 2011 1 kayıt (commit)
  35. 25 Kas, 2011 2 kayıt (commit)
  37. 16 Eyl, 2011 2 kayıt (commit)
  39. 17 May, 2011 1 kayıt (commit)
  41. 02 Mar, 2011 1 kayıt (commit)
  43. 26 Ock, 2011 1 kayıt (commit)
  45. 09 Ara, 2010 1 kayıt (commit)
  47. 03 Kas, 2010 1 kayıt (commit)
  49. 25 Eki, 2010 1 kayıt (commit)
  51. 18 Eki, 2010 1 kayıt (commit)
  53. 14 Eki, 2010 1 kayıt (commit)