On Thu, Jan 28, 2010 at 9:29 PM, Christiaan Hofman <cmhof...@gmail.com>wrote:
>
> On Jan 28, 2010, at 18:21, Maxwell, Adam R wrote:
>
> > On 01/28/10 06:00, "Christiaan Hofman" <cmhof...@gmail.com> wrote:
> >
> >> I don't remember all that was said about thread safety in relation to
> bibitems
> >> and type info. I thought that BDSKTypeInfoManager doesn't need to be
> thread
> >> safe, because it wasn't used on a secondary thread since it wasn't used
> >> anymore for file searching. That seems to be incorrect, as various
> search
> >> group servers create bibitems on a secondary thread, and that uses the
> type
> >> manager. So something has to change. Either search groups servers should
> >> always create bibitems on the main thread, or BDSKTypeManager needs to
> be
> >> thread safe. The latter can be very expensive in regular usage, because
> the
> >> various typeinfo NSString category methods are called a lot (and
> especially
> >> those should be made thread safe, because that type info can change). So
> is it
> >> feasible to create items in search groups on the main thread? I
> particularly
> >> want to ask Adam, because he wrote the search group servers.
> >
> > Realistically, the only way this could be a problem is if someone edits
> > default field prefs while while actually creating a BibItem and calling
> the
> > type manager from another thread. That's a very tiny window in practice,
> > but I agree that it's worth trying to fix.
> >
> > I think the easiest (and best-performing) way to do this would be to use
> a
> > per-thread instance of BDSKTypeManager. I implemented this in my code,
> but
> > it's only minimally tested. The only slightly tricky part is observing
> > notifications, but that's not too bad.
> >
> > Pushing all of the parsing to the main thread is probably possible, too,
> but
> > would require code changes and testing in more modules, and be a
> performance
> > hit.
>
> I think the parsing should go to the main thread. There are more reasons
> for this. For instance, the bibtex parser can only be used on the main
> thread due to global constants. Also, parsing on the background threads
> means that the pubs are archived for transfer through DO. This also means
> that there probbaly would not even be a performance gain at all.
>
> As for several type manager instances, I don't think that's a good idea.
> There are notification observations that can give problems. Also changes
> won't be properly passed to the instance in the background.
>
> I've already made some changes to the ZOOM and DBLP servers. Those are
> actually not too bad, just do everything starting from parsing on the main
> thread after sending the raw string there. For IS I am just very confused
> about what's going on there. Especially for citedReferences. It does not
> seem right to me. For instance, parsing seems to be taking place twice. The
> indentation is a bit messy, which makes it hard to read. Is it possible to
> split the code into getting the string(s) and parsing them to get pubs?
>
> Christiaan
>
>
Just thought, another, perhaps easier, solution is to first create a
dictionary containing the pubfields, pubtype, and URL, and make bibtems out
of that on the main thread.
Christiaan
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
