linuxaudio.org

--f46d0408d69b2e89b604d5f2796a

Content-Type: text/plain; charset=ISO-8859-1
On Sun, Feb 17, 2013 at 9:20 PM, Paul Coccoli  wrote:
> This scheme sounds error prone.  In general, copying C++ objects via

quoted text
> memcpy (or writing them 1 byte at a time into the ringbuffer, which is

> what I think you're proposing) is a bad idea.

Nope, write them one   sizeof( event->size() ) at a time.

I'm very interested in why copying C++ objects like this is a bad idea.

Its been discussed on list before (

http://linux-audio.4202.n7.nabble.com/Inter-thread-Communication-Design-...

).

This seemed to be the best simple RT safe solution. If you have suggestions

/ improvements I'd love to hear them.
JACK ringbuffers are

quoted text
> ideally suited to passing simple types (like floats), and not vairable

> sized things (like different derived Event classes).  Your enum for

> event types is a bit of a red flag, too.  While its perfectly valid,

> "type flags" like this more often than not accompany inflexible,

> tightly coupled code (which may be fine in a small audio app, but few

> apps stay small).

>

> What about passing pointers via the ringbuffer?
Pointers to an Event? Just makes it more hassle to send an Event from the

RT thread.

Involves taking X memory from a mem-pool, and then using placement new to

construct

the EventPlay(), and then send the pointer trough the ringbuffer. More

complicated IMO.
> To free the event  objects, you could pass them back via a second

quoted text
> ringbuffer so the RT

> threads aren't responsible for deleting them.

>

Indeed, that would be necessary. Again, more complications. That said, it

can be done,

and would involve less "traffic" trough the ringbuffer, and also "fixed

size" traffic": pointers to EventBase.

--f46d0408d69b2e89b604d5f2796a

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
On Sun, Feb 17, 2013 at 9:20 PM, Paul Co=

ccoli <pcoccoli@gmail.com> wrote:

This scheme sounds error prone. =A0In general, copying C++ objects via

memcpy (or writing them 1 byte at a time into the ringbuffer, which is

what I think you're proposing) is a bad idea. =A0Nope=

, write them one =A0 sizeof( event->size() ) at a time.I'm very =

interested in why copying C++ objects like this is a bad idea.Its been =

discussed on list before (http://linux-audio=

.4202.n7.nabble.com/Inter-thread-Communication-Design-Approach-td68710.html=

).

This seemed to be the best simple RT safe solution. If you have suggestions=

 / improvements I'd love to hear them.

JACK ringbuffers are

ideally suited to passing simple types (like floats), and not vairable

sized things (like different derived Event classes). =A0Your enum for

event types is a bit of a red flag, too. =A0While its perfectly valid,

"type flags" like this more often than not accompany inflexible,<=

br>

tightly coupled code (which may be fine in a small audio app, but few

apps stay small).=A0

What about passing pointers via the ringbuffer? =A0Pointe=

rs to an Event? Just makes it more hassle to send an Event from the RT thre=

ad.Involves taking X memory from a mem-pool, and then using placement n=

ew to construct

the EventPlay(), and then send the pointer trough the ringbuffer. More comp=

licated IMO.=A0To free the event=

=A0

objects, you could pass them back via a second ringbuffer so the RT

threads aren't responsible for deleting them.

Indeed, that would be necessary. Again, more complicatio=

ns. That said, it can be done,and would involve less "traffic&quot=

; trough the ringbuffer, and also "fixed size" traffic": poi=

nters to EventBase.
--f46d0408d69b2e89b604d5f2796a--