Skip to content
This repository was archived by the owner on Aug 12, 2020. It is now read-only.

Conversation

githubmonkey
Copy link

Hi Matt,

feel free to discard the changes to demo/main.cpp as I used them mostly to demonstrate the bug.

I do recommend you pull the update to cql_callback_storage.hpp though as it fixes the race condition reported in #44.

Cheers!

…is to highlight a potential bug inside libcql. As far as I know libcql is meant to be thread safe, but this demo

shows otherwise. A bunch of concurrent calls to pool->query() inevitably result in an exception "The associated promise has been destructed prior to the associated state becoming ready."

Hopefully, this will get the community interested in helping me debugging the demo and underlying libcql calls...
…overwrite each others callback functions.

This fixes a critical bug reported in https://github.com/mstump/libcql/issues/44
Also reduce runtime and thread number to something more reasonable. This was exaggerated to demonstrate the bug but the
problem has been addressed.
@dimitry42
Copy link
Contributor

Couple of comments about this:

  1. The callback storage is bound to io_service event loop and there should be one storage per io_service. hence it is thread local and does not need any synchronization.
  2. I'm not sure how it gets used concurrently but this needs to be fixed in the place where it happens not storage itself. The storage should not be used concurrently. every opened socket should have it's own storage instance allocated.

I'll try to do some investigation next week.

@dimitry42
Copy link
Contributor

Nevermind, I see it now. You are right, it is easier to make storage thread safe then to move stream_id allocation inside event loop.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants