On Mon, Feb 1, 2010 at 10:55 PM, Christiaan Hofman <cmhof...@gmail.com>wrote:
>
>
> On Thu, Jan 28, 2010 at 9:40 PM, Christiaan Hofman <cmhof...@gmail.com>wrote:
>
>>
>>
>> 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
>>
>>
> Actually, this solution has a problem: passing an array of dictionaries
> through DO sometimes leads to a crash. Archiving the array using
> NSKeyedArchiver solves it. It makes no sense, and I blame NSPortCoder. Pity
> I can't reproduce it in a simple test setting. Anyway, with this extra step
> it works. Still wish I could predict when Cocoa works.
>
> Christiaan
>
>
I found a bug in the yaz framework (ZOOMRecord.m line 182). This one was the
cause of a similar crasher in the ZOOM group server. Could it be that
there's some bug in the ISI server and/or its services? Unfortunately I
cannot test that.
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
