Re: [LAD] Inter thread Communication: Design Approach

On Fri, 2011-09-02 at 11:03 -0500, Gabriel Beddingfield wrote:
> On Fri, Sep 2, 2011 at 10:22 AM, David Robillard <d@email-addr-hidden> wrote:
> >> >
> >> > The main issue you'll find with going the C++/RTTI route is that #2 no
> >> > longer is possible, since virtual objects are not POD, so you can't
> >> > safely write them through a ringbuffer (or copy them around manually in
> >> > general).
> >> [snip]
> >>
> >> Correct me if I'm wrong... but...
> >>
> >> >> class event_two_t : public event_t
> >> >> {
> >> >> public:
> >> >> int type() { return int(EVENT_TWO); }
> >> >> uint32_t size() { return sizeof(event_two); }
> >> >>
> >> >> /* event-specific stuff */
> >> >> };
> >>
> >> The intention of the size() member function is to allow you to memcpy()
> >> the object without knowing its type. Is that not enough?
> >
> > Because it uses inheritance, this object is not POD, so strictly
> > speaking no.
>
> Yes, it's not strictly POD. However, the objective was to have an
> RT-safe way to pass almost-POD objects in the confines of a
> single-process, shared-memory application. In this situation, I think
> the the fact that the vtable is not POD is a non-issue because the
> pointers are all valid, static references.
>
> However, if he needs some manner of IPC, serialization, or plugin
> (loading/unloading code) scheme... then this is indeed a show stopper.

You may be able to get away with it depending on your compiler
implementation/system/phase of the moon, but since in this particular
example you're just dispatching by type anyway and gaining nothing from
using inheritance, it'd be a bit silly to do so...

This may be a hand-wavey justification, but I have seen some pretty
weird stuff happen when I treated not-strictly but pretty-much-POD
objects as POD data. Weird stuff like things working fine 99% of the
time but catastrophically exploding occasionally. Given that this is
explicitly illegal (i.e. that you don't do this is an assumption the
compiler makes), and aggressive optimization is in use, this isn't too
surprising. It's best not to tread in that dark valley, C++ is awful
enough when you follow the rules :)

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Sep 2 20:15:02 2011