Patricia,
I went back to BitBucket (thanks Pedro) to see exactly how
sal/inc/osl/profile.h,
<https://bitbucket.org/mst/ooo340/src/8b564af029aa60259c0d133d7dc37468ef56e4b5/sal/inc/osl/profile.h>
became deprecated: The file had only been touched 8 times before the form in
the AOO repro was imported. Some of those commits are tied to issue-tracker
numbers too.
The deprecation was introduced in both profile.h and profile.hxx on 2002-11-28.
There is an associated issue number but it is not in our bugzilla.
There is still no clue what this was deprecated in favor of.
- Dennis, still praying this code isn't actually used.
The TL;DR:
Here is the forensic scoop,
* 2000-09-08 1.1.1.1 already has a history nicely included at the end of the
file by CVS (or RCS), that goes back to Revision 1.1 on 1997-07-17. Locking
was apparently added in Revision 1.3 on 1997-12-12. Revision 1.6 on 1998-05-04
fixed a Unix threading problem. Flushing was added earlier in 2000 with
something about the option to flush without locking.
The history log in the code file ended when the project converted from CVS
to SVN (not Hg right away). [Now you know why I habitually write manual
histories into code and files of my own.] That history was removed in
subsequent maintenance.
NOTE: The annotations, including typos, are already the same as in the AOO
copy profile.h.
* 2002-11-28 #90284# (to mark as deprecated). THIS IS WHERE DEPRECATION WAS
INTRODUCED. This bug identifier does not correspond to an issue in the AOO
bugzilla, unfortunately, so we do not have the reasoning.
* There is a similar history for the profile.hxx that wraps the profile.h
signatures in a class wrapper. This also has introduction of the deprecation
warning.
The only use of osl_openProfile is in the Profile constructor and that
simply holds onto the returned oslProfile (a void*). The constructor throws an
exception if the oslProfile value is NULL.
The only use of osl_closeProfile in the defined Profile class is in the
destructor and it has no error checking.
Despite the sane class wrapping, there could potentially be multiple Profile
instances constructed on the same ProfileName string. Then thread
synchronization could still be needed, assuming osl_openProfile succeeds under
those conditions.
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
> Sent: Wednesday, March 2, 2016 11:42
> To: dev@openoffice.apache.org
> Subject: RE: Profile.c bugs (was RE: Some thoughts on the learning
> curve)
>
>
>
> > -----Original Message-----
> > From: Patricia Shanahan [mailto:p...@acm.org]
> > Sent: Wednesday, March 2, 2016 10:25
> > To: dev@openoffice.apache.org
> > Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
> > curve)
> >
> > Dennis,
> >
> > The build output from my Windows build contains the line:
> >
> > Compiling: sal/osl/w32/profile.cxx
> >
> > There appear to be three different implementations of the profile
> > module, profile.c for "os2", profile.c for "unx", and profile.cxx for
> > "w32". Only the "unx" version has pthread_mutex operations, including
> > our null point de-reference.
> >
> > Patricia@Jan2014Desktop /cygdrive/c/OpenOfficeDev/Trunk/main/sal/osl
> > $ grep -c pthread_mutex */profile.c */profile.cxx
> > os2/profile.c:0
> > unx/profile.c:33
> > w32/profile.cxx:0
> >
> > All three are significantly different. I think I should next try to
> > understand the difference in thread operations between them.
> [orcmid]
>
> I looked at the w32 code and the definition of the profile data
> structure and there is no use of locks whatsoever. The w32 code uses an
> oslProfile-reached structure having no mutex field. I see no lock
> checking on the way into the close function that is of concern to us. I
> trust that means there is no multi-threading that can happen into and
> out of the code on Windows [;<).
>
> In all cases, the opening and creation of the profiles apparently
> produces files somewhere. We should see if we can catch those wherever
> they are supposed to be found.
> >
> > I'll look at SVN logs to see if there is any informative history. Is
> > there any write-up I should be reading on how threading is managed on
> > the different systems?
> [orcmid]
>
> There was some conversation, ending back around 2008, on refactoring or
> stabilizing a threading model. Start here:
> <https://wiki.openoffice.org/wiki/Architecture>.
>
> The code has not been touched outside of comments since import to AOO.
> Based on the annotated file that Pedro called up, the bug is in the unx
> version code from Revision 1.1.1.1 of 2000-09-18, including the mutex in
> the struct and the logic that bothers us.
>
> There is no useful annotation whatsoever.
>
> Let's see if we can find the expected files being created/used in a
> running distribution.
>
> Then we might need to do some grep work to find out where the
> osl/profile.h, oslProfileOption type, oslProfile type, and profile
> operation references are found.
>
>
> > Patricia
> >
> >
> > On 2/29/2016 11:02 AM, Dennis E. Hamilton wrote:
> > > Patricia,
> > >
> > > Take a look at main/sal/inc/osl/profile.h
> > >
> > > Methinks that the code identified in
> > <https://bz.apache.org/ooo/show_bug.cgi?id=126669> might not be built
> > for current releases on Windows or Linux. You'll see that there are
> > filename suffixes such as .rc and .ini used. I doubt that has
> anything
> > to do with handling profiles now.
> > >
> > > Is there a way we can check that the code is not built and/or and
> > these profile functions are not used?
> > >
> > > I don't know about builds for OS/2 and other downstream builds that
> we
> > don't make ourselves.
> > >
> > > And if the code is really obsolete, we should prune it from trunk
> and
> > source releases.
> > >
> > > - Dennis
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
