Fwd: [Openmcl-devel] bogus objects

[Daniel Barlow]

Cyrus Harmon <ch-openmcl at bobobeach.com> writes:

> I thought you might be interested in this discussion with Gary Byers
> from the openmcl mailing list. I'm seeing some intermittent problems
> with araneida (and cl-blog) on openmcl that I think might be related
> to multiple threads and the way araneida does its html output inside
> of a big call to format. 

Thanks for alerting me to it, but all the html output that Araneida
does is to the socket stream directly (which is - or should be - only
visible in a single thread) or to short lifetime string streams that
are also local to the thread.  So I'm not sure what the problem is as
you describe it: /recursive/ re-entrancy should be safe, no?

I may be being stupid here: if so, please don't hesitate to explain how

>> If the shared string-output-streams that Araneida creates are basically
>> "permanent", it might be practical to  [lock them]

There are no explicitly created shared string-output-streams in
Araneida (modulo idiocy on my part, but I can't find them if so).
There's a lot of dorky code in there and I wouldn't be totally
surprised if I had been idiotic in this way, but as stream output in
general in SBCL (my usual implementation) isn't automatically
locked at all[1], I'd have to have been having a bad day.

A later message in the openmcl-devel archive seemed to indicate that
the problem was with shared access to *error-output* or something like
that.  Our usual procedure on OpenMCL if there's a handler error
involves a message on *trace-output*[2] then a backtrace printed with
(ccl:print-call-history :detailed-p nil): if there's some locking
protocol we should be observing for writing to that stream, or if this
is otherwise a bad idea, please let me (and Brian) know.  You can see
the code in compat/compat-openmcl.lisp, or

http://cvs.telent.net/cgi-bin/viewcvs.cgi/araneida/compat/compat-openmcl.lisp?rev=1.1&view=markup

if you don't want the hassle of downloading the whole thing.

[1] the argument for which goes like this: a meaningful piece of
output will in general involve more than one object being sent to the
stream.  If thread a is doing (progn (princ "hello") (terpri)) then
you need an application level lock to tell thread b not to write stuff
before the newline, becuse there's no way that the system can
tell where the end of the message is.  That being so, why introduce an
/extra/ set of locks if they will have no practical use, and the
unfortunate side-effect of making repeated write-char or write-byte
absurdly slow.  

[2] actually we should probably review our use of
attached-to-the-terminal streams; there's presently stuff being
printwed with (format t...) as well as to *trace-output*,
*error-output*, etc etc


-dan

-- 
"please make sure that the person is your friend before you confirm"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20041114/e23246b0/attachment.bin>