Threads and MulleEOF

MulleEOF and pthreads or other low level threads

MulleEOF is not aware if you run any kind of lowlevel (below Foundation) threads. If you do so and want to use them in conjunction with MulleEOF, start a dummy NSThread before starting pthreads.

Thread started during saveChanges

MulleEOF starts out in single-threaded mode and does not create locks for itself. It waits for NSThreads notification, that a thread has been started and then implements locking. This is nice but has one severe problem in AppKit applications.

The scenario is the following, one is fetching with a editingContext:shouldContinueFetchingWithCurrentObject:originalLimit:objectStore: delegate and the delegate puts up an UI, with a blinking button, so that a thread is started at that time.

The problem is, that a lock will be put into place, while we are in a routine, that should have been locked in the first place. The result is an ugly warning in 10.5 reading: -[NSRecursive lock] ... unlocked when not locked.

Solution

a) start a dummy NSThread before invoking EOF saves.

b) ignore harmless warning