qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fj <fj.m...@gmail.com>
Subject [qpid-proton-cpp] default_container does not implement thread safety at all?
Date Mon, 13 Mar 2017 23:23:54 GMT
Hello, I'm mightily confused.

There's
https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/cpp/api/md_mt.html
that says in no uncertain terms that I can use event_loop.inject() to
execute a callback on the thread that runs the event loop. There's an
examples/cpp/mt/broker.cpp linked from the above that's supposed to be a
thread safe implementation of a thread pool running a bunch of containers.

But after "grep inject" and carefully sifting through the results, it seems
that after some indirection it all ends up calling

// FIXME aconway 2016-06-07: this is not thread safe. It is sufficient for
using
// default_container::schedule() inside a handler but not for inject() from
// another thread.
bool event_loop::impl::inject(void_function0& f) {
    try { f(); } catch(...) {}
    return true;
}

What the hell? Blank exception suppression is just the icing on the cake,
nothing here even resembles doing the actual hard thing: telling the
reactor to inject a new custom event in a threadsafe manner.

Am I missing something obvious, or is the documentation there, and in other
places, and the example, chemically pure wishful thinking, like, it would
be pretty nice if we supported multithreading, and it would work in such
and such ways then, but unfortunately we don't, as a matter of fact?

If so, maybe you gals and guys should fix the documentation, and not just
with "experimental" but with "DOESN'T WORK AT ALL" prominent on the page?

----------------

On more constructive notes:

1) do people maybe use some custom containers, similar to the
epoll_container in the examples (which doesn't support schedule() though, I
have to point out)? If so, I much desire to see one.

2) why do you attempt to bolt on your event_loop thing to Connection and
below when the only thing that has the run() method is Container, therefore
that's the scope that any worker thread would have? It's the Container that
should have the inject() method. Underlying C API notwithstanding.

3) What's the best way forward if I really have to have a threadsafe
container that I can inject some event into threadsafely:

  3a) does the C API support thread safety? Like, the whole problem is
touching the reactor's job queue or whatever it has with taking an
appropriate lock, and it must take that same lock itself for it to work.

  3b) I checked out the Python API, they use a mock EventInjector pollable
thingie instead of reaching inside the reactor and telling it add an event.

  3c) epoll example does yet another thing apparently (though I'm not sure
it works because it's not covered by any tests): just tell the reactor to
wake up and process the queued job list in your handler.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message