On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote:
-----Original Message-----
From: Patricia Shanahan [mailto:[email protected]]
Sent: Thursday, March 3, 2016 14:38
To: [email protected]
Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
curve)
I am seriously considering starting a project to eliminate profile.c
etc. and seeing what, if anything, breaks.
Before I do that, I have a question about whether it could be accessed
through any of OpenOffice's extension or plugin facilities? Even if it
can, 14 years seems quite long enough for people to migrate off a
deprecated interface.
[orcmid]
I think the extensions and plugins depend on UNO objects. So long as that is
the case, the profile code should be unreachable.
Meanwhile, can you tell me how to use BitBucket to look at the original
version of the w32 profile code? [ ... ]
[orcmid]
If you go to a page that we already have a link for, such as
<https://bitbucket.org/mst/ooo340/src/8b564af029aa60259c0d133d7dc37468ef56e4b5/sal/inc/osl/profile.h>
You'll see the file path "mouse tracks" at the top of the page just above all the
information about multiple heads of the default branch. You can walk back up the tree and
down to the page you want [;<).
I am curious about whether it started
out with pthread_mutex uses and lost them along the way, or whether that
difference between unx and w32 is primordial.
[orcmid]
You made me look :). Apparently sal/osl/w32/profile.cxx sprang primordially
from the earth on 2010-01-29. I have to believe there was an older one,
possibly named profile.c but deleted and not shown in the bitbucket.
I checked the os2 version. It has profile.c BitBucket history back to
2000, presumably because the file did not get renamed. The 2000 version
does not have pthread_mutex calls.
This leaves a serious mystery, and a far bigger problem than the
original null pointer de-reference. It seems very unlikely to me that it
is right for Profile to do its own synchronization in "unx" systems, but
not for "w32" or "os2". Presumably, whatever the thread safety rules are
for Profile, they should be the same on all the systems to avoid
exporting operating system dependency throughout the application.
I think my next step may be to start a wider investigation of where
pthread functions are called directly.
Patricia
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
