[zeromq-dev] Race conditions again
Apostolis Xekoukoulotakis
xekoukou at gmail.com
Tue Jan 7 14:53:57 CET 2014
You can send a signal with inproc. But the main problem with that is that
the same data might need to be consumed by many processes. That cannot
happen with signals. One way to solve that would be to have immutable data
that act only as input.
2014/1/7 Lindley French <lindleyf at gmail.com>
> Inproc messaging is great in concept, but the need to serialize data seems
> like it could be a bottleneck. An alternative that preserves objects in C++
> is QT signals. Unlike most other sig/slot libraries, QT slots on a QObject
> can be configured to always run on the same thread no matter which thread
> emits the signal. This makes it easy to use them for inter thread
> communication.
>
> Of course, there is also value in using the same API for inter thread and
> inter host communication. The right tool for the right job, and all that.
>
> > On Jan 7, 2014, at 12:31 AM, Pieter Hintjens <ph at imatix.com> wrote:
> >
> > I've never used thread sanitizer. Two things strike me. First, if
> > there are *real* race conditions, you can help by tracking these down
> > and working with us to fix them. Secondly, if these are false
> > positives, there must be some "ignore" file, as we use for valgrind.
> >
> > As for race conditions in your own code, if you do not use shared
> > mutable state, and only pass data between threads via messages, there
> > is no opportunity for race conditions in your own code.
> >
> > -Pieter
> >
> >
> >
> >> On Tue, Jan 7, 2014 at 2:24 AM, Michi Henning <michi at triodia.com>
> wrote:
> >> Hi folks,
> >>
> >> I've been using zmq (3.2.3) with good success, but I'm getting a lot of
> noise from
> >> clang's thread sanitizer about race conditions.
> >>
> >> I've compiled both 3.2.3 and 4.0.3 with clang and thread sanitizer
> enabled.
> >> Running the test suite generates hundreds of reports of race conditions.
> >> It appears that many of these are harmless (at least, I haven't seen
> any crashes).
> >> But getting all this noise from thread sanitizer makes it very
> difficult to use the
> >> tool because any race conditions that I introduce in my own code are
> very hard
> >> to spot in all the noise. (Thread sanitizer does have a suppression
> mechanism,
> >> but it's quite coarse, nowhere near as fine-grained as, say,
> valgrind's.)
> >>
> >> In my experience, problems reported by thread sanitizer are generally
> worth
> >> paying attention to. (There are few false positives.)
> >>
> >> Is there any chance of getting a zmq release that runs clean with
> thread sanitizer?
> >>
> >> Thanks,
> >>
> >> Michi.
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
--
Sincerely yours,
Apostolis Xekoukoulotakis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140107/4e4f8c26/attachment.htm>
More information about the zeromq-dev
mailing list