cl-dbi icon indicating copy to clipboard operation
cl-dbi copied to clipboard

Functions connect-cached and get-connection-pool are not thread-safe

Open svetlyak40wt opened this issue 5 years ago • 4 comments
trafficstars

Because of that, Ultralisp sometimes fails with this error:

failed AVER:
    (= (HASH-TABLE-COUNT SB-IMPL::TABLE) SB-IMPL::HWM)
This is probably a bug in SBCL itself. (Alternatively, SBCL
might have been corrupted by bad user code, e.g. by an undefined
Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers
from alien code or from unsafe Lisp code; or there might be a
bug in the OS or hardware that SBCL is running on.) If it seems
to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists,
which you can find at <http://sbcl.sourceforge.net/>.
   [Condition of type SB-INT:BUG]

Restarts:
 0: [ABORT] abort thread (#<THREAD "searching-for-repositories" RUNNING {102F529873}>)

Backtrace:
 0: (SB-IMPL::GROW-HASH-TABLE #<HASH-TABLE :TEST EQ :COUNT 35 {10020957B3}>)
 1: ((FLET SB-IMPL::INSERT-AT :IN SB-IMPL::GET-PUTHASH-DEFINITIONS) #<unavailable argument> #<HASH-TABLE :TEST EQ :COUNT 35 {10020957B3}> #<SB-THREAD:THREAD "searching-for-repositories" RUNNING {102F52987..
 2: (SB-IMPL::PUTHASH/EQ #<SB-THREAD:THREAD "searching-for-repositories" RUNNING {102F529873}> #<unavailable argument> #<unavailable argument>)
 3: (SB-KERNEL:%PUTHASH #<SB-THREAD:THREAD "searching-for-repositories" RUNNING {102F529873}> #<HASH-TABLE :TEST EQ :COUNT 35 {10020957B3}> #<HASH-TABLE :TEST EQUAL :COUNT 0 {102F5305A3}>)
 4: (DBI:CONNECT-CACHED :POSTGRES :HOST "172.17.0.1" :DATABASE-NAME "ultralisp" :USERNAME "ultralisp" :PASSWORD "****")
 5: (ULTRALISP/DB::CONNECT :HOST NIL :DATABASE-NAME NIL :USERNAME NIL :PASSWORD NIL :CACHED T)
 6: ((LAMBDA NIL :IN ULTRALISP/GITHUB/WIDGETS/REPOSITORIES::SET-OAUTH-TOKEN))
 7: ((LABELS BORDEAUX-THREADS::%BINDING-DEFAULT-SPECIALS-WRAPPER :IN BORDEAUX-THREADS::BINDING-DEFAULT-SPECIALS))

This code short be protected with lock.

svetlyak40wt avatar Nov 03 '20 21:11 svetlyak40wt

As a workaround, you may recreate the hash from time to time:

(setf cl-dbi::*threads-connection-pool* (cl-dbi::make-threads-connection-pool))

svetlyak40wt avatar Nov 03 '20 21:11 svetlyak40wt

Thank you for reporting. Adding :synchronized t to make-hash-table might work?

fukamachi avatar Nov 13 '20 08:11 fukamachi

As I understand, :synchronized t is SBCL's extensions and will not work on other implementations.

Probably we need a separate system to work this around? Something like trivial-sychronized.?

svetlyak40wt avatar Nov 13 '20 08:11 svetlyak40wt

As I see some sort of synchronization was already added: https://github.com/fukamachi/cl-dbi/blob/738a74dd69adb2a7c21fa67e140d89c7df25b227/src/cache/thread.lisp#L37

And today I've fixed it a little in this pull-request:

https://github.com/fukamachi/cl-dbi/pull/75

svetlyak40wt avatar Sep 24 '22 21:09 svetlyak40wt