Hi, Mark
The problem definition in the pdu.lisp is this two:
#-portable-threads (defmethod generate-request-id ((pdu common-pdu)) (with-slots (request-id-counter) pdu (the (unsigned-byte 32) (logand (incf request-id-counter) #xffffffff))))
#+portable-threads (defmethod generate-request-id ((pdu common-pdu)) (with-slots (request-id-counter) pdu (the (unsigned-byte 32) (logand (portable-threads:atomic-incf request-id-counter) #xffffffff))))
The only difference between two versions, is the use of INCF being replaced to ATOMIC-INCF, which is a thread-safe version of INCF.
If I always use the first version in ABCL (there's another similar method in message.lisp), than ABCL can pass this, and directly goes to the second issue (it's definitely CLOS related, I think)...
I wrote some basic extension code for GBBopen's portable-threads.lisp to support threading in ABCL (no cond var), and the form
(portable-threads:atomic-incf request-id-counter)
will be macro-expanded into
(PORTABLE-THREADS:AS-ATOMIC-OPERATION (INCF REQUEST-ID-COUNTER 1))
then
(PORTABLE-THREADS:WITH-LOCK-HELD (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
and then (simplified)
(THREADS:WITH-MUTEX (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
Consider ATOMIC-INCF itself works just right. I think maybe ABCL compiler cannot handle a macro form inside method definition quite well, shouldn't be CLOS/MOP's fault.
Hope this helps.
Regards,
Chun Tian (binghe)
在 2011-3-21，00:17， Mark Evenson 写道：
On 3/20/11 4:52 PM, Chun Tian (binghe) wrote:
[…]
Now I need help. If one could spend 5 minutes do a SVN checkout of the release branch:
https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/branches/6
and try to ASDF load it (you'll need usocket 0.5 and ironclad), two major CLOS bug of ABCL will show up, one is at "pdu.lisp", as what the mail title said, The value :LONG is not of type (MEMBER NIL :BOOLEAN).
I have reproduced your error with ABCL trunk.
I have no idea how to fix it.
It is not immediately clear whether this is actually CLOS or the compiler, as the file seems to eval without errors. We'll need a little time to investigate but hopefully we'll have you on your way to SNMP land in Java via CL in no time…
Thanks for the bug report.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel