[bknr-devel] threads with bknr-datastore

[Hans Hübner]

Hi Kamen,

I have cross-checked the problem you pointed at, and in fact it is
true:  The file copying operation of the blob creation routines is not
guarded against other processes accessing the datastore.  I have not
delved into this very far, but I suspect that under CMUCL and
SERVE-EVENT based multiprocessing, no scheduling will occur during the
file I/O operation, as the scheduler will run only when a file
descriptor under control of the SERVE-EVENT subsystem is accessed. 
This is a guess only, though, and I have not looked up the source to
verify what's going on.  With a threaded Lisp, the mechanism could be
much more problematic as the scheduler may run at any time and
pre-empt the Lisp process, possibly in the middle of the file-copying
operation.

It depends on your application if this is a problem.  If your
application does not use the blob until it has been put into some
application-defined data structure (as opposed to using the class'
index), the incomplete blob will be no problem - Only the external
data will not be complete.

As we started implementing the datastore, we decided that the blob I/O
operations should not be protected by the datastore locks, as this
would possibly stall the system for a long time.  This may or may not
be good for your application, but it would require further analysis to
really make a good judgement if blob writing should be further
protected.  This could, for example, be done with a "complete" slot
that would be set after the blob has been completely written, in a
seperate store transaction.

Note that cmucl provides cooperative multiprocessing which is
preferable to preemptive threading in many respects.  It is simpler to
understand, implement and debug.  The only real disadvantage it has
(in my eyes, anyway), is the fact that no two processes can run at the
same time, if two CPUs are available.

Cheers,
Hans