[LyX/master] Cmake export tests: Omit next group of possible conflicts while runnig test in parallel

[Scott Kostyshak]

On Thu, Aug 20, 2020 at 01:57:37PM +0200, Kornel Benko wrote:
> Am Thu, 20 Aug 2020 09:47:27 +0200
> schrieb Kornel Benko <kornel at lyx.org>:
> 
> > Am Wed, 19 Aug 2020 16:57:44 -0400
> > schrieb Scott Kostyshak <skostysh at lyx.org>:
> > 
> > > On Wed, Aug 19, 2020 at 10:09:36PM +0200, Kornel Benko wrote:  
> > > > commit 4bb00e99fbc4e23075088dfdd8e3d566fbd9d187
> > > > Author: Kornel Benko <kornel at lyx.org>
> > > > Date:   Wed Aug 19 22:28:50 2020 +0200
> > > > 
> > > >     Cmake export tests: Omit next group of possible conflicts while runnig test in
> > > > parallel 
> > > >     Disable conversion cache because all lyx instances use the same cache without
> > > >     any locking between read and write to the cache.
> > > >     
> > > >     Thanks to Scott catching this case.
> > > > ---    
> > > 
> > > Thanks, Kornel. I tried to lock the cache index when writing (patch
> > > attached), but that's just the index file. I suppose we would need to
> > > lock each cache file created. I can give that an attempt if someone can
> > > take a look at the attached patch for the index and let me know if it
> > > seems like the correct approach and I can try it for the cache files
> > > themselves.
> > > 
> > > Before working on that, I would like to ask if it's desirable to have
> > > that in the core code. I don't have a feeling for whether a user is
> > > likely to be bitten by this. In theory, it seems that a user could be
> > > bitten by this issue if they just open/export the same .lyx file in more
> > > than one process. I'm not sure why they would do that though (perhaps by
> > > mistake?). Also, conditional upon being bitten by the issue, I'm not
> > > sure if it is that bad. I guess it could be viewed as bad if a user does
> > > not realize (i.e., no compilation error) if a file in the cache is
> > > corrupt, but I would guess that a corrupt file would lead to a
> > > compilation error more often than not.
> > > 
> > > Thoughts?
> > > 
> > > Scott  
> > 
> > I am not sure if this would block other instances for a long time
> > 
> > 	Kornel
> 
> On a second look, I think that ConverterCache::Impl::readIndex() also should use locking.

Good point. I guess ideally we would have a writer/reader lock
implementation. It's fine if multiple readers want to simultaneously
read it.

Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200820/5833257b/attachment-0001.asc>