20 Aug
2011
20 Aug
'11
4:19 p.m.
Hey All,
I'm looking to improve a program's design with regards to how it
communicates between the "jack" thread and its "main/gui" thread.
Please
note I'm *not* looking for implementation details like what ringbuffer to
use, this has been discussed here before.
Conditions:
Gui needs to feed data trough to the jack thread (data = parameter moves
etc)
Jack thread needs to push data (buffers for waveforms & "playhead" info)
The real question:
What is a neat solution to passing various data trough a ringbuffer?
My (hacky?) solution: Create a class, call it "Event". Runtime now looks
like so:
1. Create a EventType enum, set the details
2. Write those "Events" into the ringbuffer
3. Switch based on EventType, and handle the event.
While not terribly ugly, that Event class starts to get bigger & nastier, so
I concidered sub-classing it... but I'm not sure this is going in the right
direction.
I'm very intrested how the "big" programs around have approached this
problem... Cheers, -Harry
20 Aug
20 Aug
5:04 p.m.
On 08/20/2011 09:19 AM, Harry van Haaren wrote:
My (hacky?) solution: Create a class, call it
"Event". Runtime now looks
like so:
1. Create a EventType enum, set the details
2. Write those "Events" into the ringbuffer
3. Switch based on EventType, and handle the event.
While not terribly ugly, that Event class starts to get bigger &
nastier, so I concidered sub-classing it... but I'm not sure this is
going in the right direction.
IMHO, You're more or less going in the right direction. There's two
main ways to structure your EventType.. and they are both essentially
using inheritance. We'll call them "The C way" and "The C++ Way".
They
are more or less equivalent.
Consider the following to be pseudocode. I didn't test it.
THE C WAY
=========
struct base_event_t_ {
uint16_t type;
uint16_t size;
};
typedef struct base_event_t_ base_event_t;
#define EVENT_ONE 1
struct event_one_t_ {
uint16_t type;
uint16_t size; /* must be EVENT_ONE */
/* extra event-specific data */
};
typedef struct event_one_t_ event_one_t;
#define EVENT_TWO 2
struct event_two_t_ {
uint16_t type;
uint16_t size; /* must be EVENT_TWO */
/* extra event-specific data */
};
typedef struct event_one_t_;
/* ... */
void my_function(event_t *ev)
{
switch(ev->type) {
case EVENT_ONE:
handle_event_one( (event_one_t*) ev );
break;
case EVENT_TWO:
handle_event_two( (event_two_t*) ev );
break;
}
}
DISADVANTAGE: You have to manually manage the type and size arguments.
THE C++ WAY
===========
class event_t
{
public:
enum {
EVENT_ONE = 1,
EVENT_TWO = 2
}; /* note: using an enum isn't necc. */
virtual ~event_t() {}
int type() = 0;
uint32_t size() = 0;
};
class event_one_t : public event_t
{
public:
int type() { return int(EVENT_ONE); }
uint32_t size() { return sizeof(event_one); }
/* event-specific stuff */
};
class event_two_t : public event_t
{
public:
int type() { return int(EVENT_TWO); }
uint32_t size() { return sizeof(event_two); }
/* event-specific stuff */
};
/* ... */
void my_function(const event_t& ev)
{
switch(ev->type()) {
case event_t::EVENT_ONE:
handle_event_one( dynamic_cast<const event_one_t>(ev) );
break;
case event_t::EVENT_TWO:
handle_event_two( dynamic_cast<const event_two_t>(ev) );
break;
}
}
DISADVANTAGE: Using dynamic_cast<> uses RTTI and can have a performance
penalty... but guards against programming mistakes (throwing an
exception if cast is invalid). Switch to reinterpret_cast<> if speed is
a problem.
-gabriel
5:57 p.m.
On Saturday 20 August 2011 17:04:46 Gabriel Beddingfield wrote:
DISADVANTAGE: Using dynamic_cast<> uses RTTI
and can have a performance
penalty... but guards against programming mistakes (throwing an
exception if cast is invalid). Switch to reinterpret_cast<> if speed is
a problem.
This performance penalty might hit you when you do one such message for every
sample of audio, it will have no practical effect when its just the user
interface signaling other parts of the app.
Have fun,
Arnold
6:17 p.m.
On Sat, Aug 20, 2011 at 4:04 PM, Gabriel Beddingfield <gabrbedd(a)gmail.com>wrote;wrote:
IMHO, You're more or less going in the right
direction. There's two main
ways to structure your EventType.. and they are both essentially using
inheritance. We'll call them "The C way" and "The C++ Way".
They are more
or less equivalent.
Thanks for that! I like the C++ way, it seems more in line with my way of
doing things...
I spose I just gotta go derive some classes now :)
Cheers, -Harry
1 Sep
1 Sep
8:18 p.m.
On Sat, 2011-08-20 at 10:04 -0500, Gabriel Beddingfield wrote:
On 08/20/2011 09:19 AM, Harry van Haaren wrote:
> My (hacky?) solution: Create a class, call it "Event". Runtime now looks
> like so:
> 1. Create a EventType enum, set the details
> 2. Write those "Events" into the ringbuffer
> 3. Switch based on EventType, and handle the event.
>
> While not terribly ugly, that Event class starts to get bigger &
> nastier, so I concidered sub-classing it... but I'm not sure this is
> going in the right direction.
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).
You can, of course, copy around *pointers* to them. This means you have
to dynamically allocate them. If you want to be able to create events in
a real-time thread, you will have to get into more advanced C++ and make
a custom allocator for that etc. etc.
In short, be wary of going too far in the C++/new/RTTI/virtual route for
events. It's not necessarily a bad solution, but if you might want to do
a bit more fancy things like send events through a pipe some day, it's
not what you want to do. There's a lot to be said for POD events.
Also, this is odd:
class event_two_t : public event_t
{
public:
int type() { return int(EVENT_TWO); }
uint32_t size() { return sizeof(event_two); }
/* event-specific stuff */
};
/* ... */
void my_function(const event_t& ev)
{
switch(ev->type()) {
case event_t::EVENT_ONE:
handle_event_one( dynamic_cast<const event_one_t>(ev) );
break;
case event_t::EVENT_TWO:
handle_event_two( dynamic_cast<const event_two_t>(ev) );
break;
}
}
If you're going to go with the inheritance route anyway, just use a
virtual ev->execute() method so the code for all events doesn't have to
be in the same place. Assuming you'll have enough that this is actually
a benefit anyway...
Cheers,
-dr
8:37 p.m.
On Thu, Sep 01, 2011 at 02:18:25PM -0400, David Robillard wrote:
If you're going to go with the inheritance route
anyway, just use a
virtual ev->execute() method so the code for all events doesn't have to
be in the same place. Assuming you'll have enough that this is actually
a benefit anyway...
That's assuming that the event's virtual execute() has access to
all it needs. In all cases I've encountered that is not the case:
the event triggers something in the context where it is received
and processing it requires access to that context's data.
It's a problem for which I don't know a clean C++ solution.
Ciao,
--
FA
9:54 p.m.
On Thu, Sep 1, 2011 at 2:37 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
That's assuming that the event's virtual
execute() has access to
all it needs. In all cases I've encountered that is not the case:
the event triggers something in the context where it is received
and processing it requires access to that context's data.
It's a problem for which I don't know a clean C++ solution.
depending on the exact type of thing you're talking about, isn't this
is place for closures, functors, etc. etc. ?
10:34 p.m.
On Thu, 2011-09-01 at 15:54 -0400, Paul Davis wrote:
On Thu, Sep 1, 2011 at 2:37 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
The event pretty much is a glorified closure, but, alas, the multiple
contexts of execution complicate it so you have to manually store what
are actually the 'parameters' and such so you can do the work later.
In less primitive languages you might be able to do something nice with
actual closures and continuations, but... oh well.
-dr
That's assuming that the event's virtual
execute() has access to
all it needs. In all cases I've encountered that is not the case:
the event triggers something in the context where it is received
and processing it requires access to that context's data.
It's a problem for which I don't know a clean C++ solution.
depending on the exact type of thing you're talking about, isn't this
is place for closures, functors, etc. etc. ?
10:36 p.m.
On Thu, Sep 1, 2011 at 4:33 PM, David Robillard <d(a)drobilla.net> wrote:
On Thu, 2011-09-01 at 15:54 -0400, Paul Davis wrote:
the execute member can be a functor rather than a virtual function, for example.
On Thu, Sep 1, 2011 at 2:37 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
The event pretty much is a glorified closure, but, alas, the multiple
contexts of execution complicate it so you have to manually store what
are actually the 'parameters' and such so you can do the work later.
In less primitive languages you might be able to do something nice with
actual closures and continuations, but... oh well. That's assuming that the event's virtual
execute() has access to
all it needs. In all cases I've encountered that is not the case:
the event triggers something in the context where it is received
and processing it requires access to that context's data.
It's a problem for which I don't know a clean C++ solution.
depending on the exact type of thing you're talking about, isn't this
is place for closures, functors, etc. etc. ?
2 Sep
2 Sep
12:04 p.m.
On Thu, Sep 01, 2011 at 03:54:03PM -0400, Paul Davis wrote:
On Thu, Sep 1, 2011 at 2:37 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
Yes, but
1. I find functor syntax extremely clumsy, involving the creation of
a specific derived functor class (from a template class) for each
one you need.
2. AFAIK (using the terminology of <http://www.newty.de/fpt/functor.html>,
you can't have a TSpecificFunctor member in the event class and
initialise it, it has to be a TSpecificFunctor*. Which in turn
means that at the sender side you either have instances of all
possibly required functor classes available and assign the
TSpecificFunctor* in the event from one of them, or you have to
use new() to allocate one. The former is extremely clumsy, and
the latter shouldn't be done in a RT context.
What I'm missing in C++ is a built-in 'functor' type that can
simply be assigned from any object::method, with the user being
responsible for the existence of the object and for supplying the
right arguments at the time the functor is called.
Ciao,
--
FA
That's assuming that the event's virtual
execute() has access to
all it needs. In all cases I've encountered that is not the case:
the event triggers something in the context where it is received
and processing it requires access to that context's data.
It's a problem for which I don't know a clean C++ solution.
depending on the exact type of thing you're talking about, isn't this
is place for closures, functors, etc. etc. ? 
12:49 p.m.
On 09/02/2011 12:04 PM, Fons Adriaensen wrote:
On Thu, Sep 01, 2011 at 03:54:03PM -0400, Paul Davis
wrote:
boost::function<void(void)> serves this purpose for me in jass. To
create and pass a functor that assigns a new auditor generator to the
one in the engine, and then tells it to play i do for example:
write_blocking_command(assign(engine_.auditor_gen, p));
write_blocking_command(boost::bind(&engine::play_auditor,
boost::ref(engine_))); assign() is just a utility template to make
creating functors that do assignments easier.. boost::bind is used to
make all passed functors 0-ary (e.g for binding member functions to
their instance or binding arguments to the functor.. and
write_blocking_command is just a utility function that disables the GUI
until the acknowledgement from the engine has come back to the GUI,, The
command ringbuffer is just a ringbuffer holding
boost::fucntion<void(void)> objects..
typedef ringbuffer<boost::function<void(void)> > command_ringbuffer;
Examples from here:
https://github.com/fps/jass/blob/master/main_window.h
https://github.com/fps/jass/blob/master/assign.h
https://github.com/fps/jass/blob/master/engine.h Regards, Flo
On Thu, Sep 1, 2011 at 2:37 PM, Fons
Adriaensen<fons(a)linuxaudio.org> wrote:
Yes, but
1. I find functor syntax extremely clumsy, involving the creation of
a specific derived functor class (from a template class) for each
one you need.
2. AFAIK (using the terminology of<http://www.newty.de/fpt/functor.html>,
you can't have a TSpecificFunctor member in the event class and
initialise it, it has to be a TSpecificFunctor*. Which in turn
means that at the sender side you either have instances of all
possibly required functor classes available and assign the
TSpecificFunctor* in the event from one of them, or you have to
use new() to allocate one. The former is extremely clumsy, and
the latter shouldn't be done in a RT context.
What I'm missing in C++ is a built-in 'functor' type that can
simply be assigned from any object::method, with the user being
responsible for the existence of the object and for supplying the
right arguments at the time the functor is called.
That's assuming that the event's virtual
execute() has access to
all it needs. In all cases I've encountered that is not the case:
the event triggers something in the context where it is received
and processing it requires access to that context's data.
It's a problem for which I don't know a clean C++ solution.
depending on
the exact type of thing you're talking about, isn't this
is place for closures, functors, etc. etc. ? Ciao,
1:50 p.m.
On Fri, Sep 2, 2011 at 6:04 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Thu, Sep 01, 2011 at 03:54:03PM -0400, Paul Davis
wrote:
i'm pretty confused by what you've written here. i use functors which
have copy semantics, and the "event" classes that contain a functor do
not contain a pointer to a functor, but a functor that is copied. this
is the base class:
struct BaseRequestObject {
RequestType type;
bool valid;
InvalidationRecord* invalidation;
boost::function<void()> the_slot;
BaseRequestObject() : valid (true), invalidation (0) {}
};
the "type" member is still there, but differentiates between requests
that require use of the functor ("the_slot") and those that are just
an enum that can be handled with no data (e.g. telling an event
loop/thread to quit).
On Thu, Sep 1, 2011 at 2:37 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
Yes, but
1. I find functor syntax extremely clumsy, involving the creation of
a specific derived functor class (from a template class) for each
one you need.
2. AFAIK (using the terminology of <http://www.newty.de/fpt/functor.html>,
you can't have a TSpecificFunctor member in the event class and
initialise it, it has to be a TSpecificFunctor*. Which in turn
means that at the sender side you either have instances of all
possibly required functor classes available and assign the
TSpecificFunctor* in the event from one of them, or you have to
use new() to allocate one. The former is extremely clumsy, and
the latter shouldn't be done in a RT context. That's assuming that the event's virtual
execute() has access to
all it needs. In all cases I've encountered that is not the case:
the event triggers something in the context where it is received
and processing it requires access to that context's data.
It's a problem for which I don't know a clean C++ solution.
depending on the exact type of thing you're talking about, isn't this
is place for closures, functors, etc. etc. ? What I'm missing in C++ is a built-in
'functor' type that can
simply be assigned from any object::method, with the user being
responsible for the existence of the object and for supplying the
right arguments at the time the functor is called.
both boost::function and sigc::mem_fun serve these roles for me. i've
stopped using sigc::mem_fun for anything other than GUI event
callbacks because sigc++ is fundamentally not thread safe, but the
easy syntax of both these forms is similar.
3 Sep
3 Sep
11:25 p.m.
On Fri, Sep 02, 2011 at 07:50:17AM -0400, Paul Davis wrote:
i'm pretty confused by what you've written
here. i use functors which
have copy semantics, and the "event" classes that contain a functor do
not contain a pointer to a functor, but a functor that is copied. this
is the base class:
struct BaseRequestObject {
RequestType type;
bool valid;
InvalidationRecord* invalidation;
boost::function<void()> the_slot;
BaseRequestObject() : valid (true), invalidation (0) {}
};
the "type" member is still there, but differentiates between requests
that require use of the functor ("the_slot") and those that are just
an enum that can be handled with no data (e.g. telling an event
loop/thread to quit).
Mmm. Did you ever look at what's going on behind the scenes
(/usr/include/boost/function/function/function_base.hpp) ?
Calling a void function(void) is a basic language operation,
supported directly by most CPU instruction sets and normally
translating into just a few CPU instrunctions. If doing this
requires > 900 lines of code (plus all the files included from
the one referred to) I'd say there is something fundamentally
wrong. Even emulating a function call on a different CPU or
a virtual one doesn't take anything like that.
Ciao,
--
FA
4 Sep
4 Sep
2:42 a.m.
On Sat, Sep 3, 2011 at 5:25 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Fri, Sep 02, 2011 at 07:50:17AM -0400, Paul Davis
wrote:
this is a complete diversion from the point i was making.
if the functor has copy semantics, its not true that you must have a
pointer to the functor in an event/request structure.
the issues with the performance of boost::function are reasonably well
known and were well documented in the article that florian linked to,
along with a much better performing drop-in replacement.
i'm pretty confused by what you've
written here. i use functors which
have copy semantics, and the "event" classes that contain a functor do
not contain a pointer to a functor, but a functor that is copied. this
is the base class:
struct BaseRequestObject {
RequestType type;
bool valid;
InvalidationRecord* invalidation;
boost::function<void()> the_slot;
BaseRequestObject() : valid (true), invalidation (0) {}
};
the "type" member is still there, but differentiates between requests
that require use of the functor ("the_slot") and those that are just
an enum that can be handled with no data (e.g. telling an event
loop/thread to quit).
Mmm. Did you ever look at what's going on behind the scenes
(/usr/include/boost/function/function/function_base.hpp) ?
Calling a void function(void) is a basic language operation,
supported directly by most CPU instruction sets and normally
translating into just a few CPU instrunctions. If doing this
requires > 900 lines of code (plus all the files included from
the one referred to) I'd say there is something fundamentally
wrong. Even emulating a function call on a different CPU or
a virtual one doesn't take anything like that.
2:45 a.m.
On Sat, Sep 3, 2011 at 8:42 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Sat, Sep 3, 2011 at 5:25 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
> On Fri, Sep 02, 2011 at 07:50:17AM -0400, Paul Davis wrote:
>
>> i'm pretty confused by what you've written here. i use functors which
>> have copy semantics, and the "event" classes that contain a functor do
>> not contain a pointer to a functor, but a functor that is copied. this
>> is the base class:
>>
>> struct BaseRequestObject {
>> RequestType type;
>> bool valid;
>> InvalidationRecord* invalidation;
>> boost::function<void()> the_slot;
>>
>> BaseRequestObject() : valid (true), invalidation (0) {}
>> };
>>
>> the "type" member is still there, but differentiates between requests
>> that require use of the functor ("the_slot") and those that are just
>> an enum that can be handled with no data (e.g. telling an event
>> loop/thread to quit).
>
> Mmm. Did you ever look at what's going on behind the scenes
> (/usr/include/boost/function/function/function_base.hpp) ?
>
> Calling a void function(void) is a basic language operation,
> supported directly by most CPU instruction sets and normally
> translating into just a few CPU instrunctions.
btw, i also feel that you may have missed the point of the declaration
of boost::function<void()>
it does NOT mean that the function that will be executed by operator()
of the boost::function is a void function(void). it means that
operator() can be called without arguments and does return a result.
the actual function executed may take any number of arguments that
will be marshalled from within the functor itself.
its very easy to write a super-fast functor in C++ - i've done one
that barely ends up with any more instructions than a direct function
call. this does not, alas, translate into something usable in all the
ways that things like sigc::mem_fun or boost::function are. the
complexities become more apparent once you try an implementation
yourself.
12:22 p.m.
On 09/04/2011 02:42 AM, Paul Davis wrote:
the issues with the performance of boost::function are
reasonably well
known and were well documented in the article that florian linked to,
along with a much better performing drop-in replacement.
Correction: It wasn't me ;D It was Pedro Alves who posted that link. I
was not aware of these performance issues. And in my usecase they are
irrelevant, so I'll stick with boost::function. For other designs it
might be worth reconsidering though..
Flo
1 Sep
1 Sep
10:30 p.m.
On Thu, 2011-09-01 at 18:37 +0000, Fons Adriaensen wrote:
On Thu, Sep 01, 2011 at 02:18:25PM -0400, David
Robillard wrote:
Sure, it would almost certainly not be a method with no parameters, most
likely you would pass some context object as a parameter which contains
all the necessary things.
-dr
If you're going to go with the inheritance
route anyway, just use a
virtual ev->execute() method so the code for all events doesn't have to
be in the same place. Assuming you'll have enough that this is actually
a benefit anyway...
That's assuming that the event's virtual execute() has access to
all it needs. In all cases I've encountered that is not the case:
the event triggers something in the context where it is received
and processing it requires access to that context's data.
It's a problem for which I don't know a clean C++ solution.
10:37 p.m.
On Thu, Sep 1, 2011 at 7:18 PM, David Robillard <d(a)drobilla.net> 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).
True, I'm currently just adding functions to an existing class, rather than
the subclassing option. That makes reading / writing the class to/from a
ringbuffer easier, as they're all the same size... For performance I'm aware
that its causing extra work, but for simplicity I'm going to keep it this
way :D
The uglest bit of having one class is having a fixed amount of variables,
and only some are being used. I've circumvented madness by creating set()
functions, that initialize the "type" variable, and also takes the right
parameters for that event type & stores them in the class. Does mean that
there's some pointless data being transferred into / outta the JACK thread
using the ringbuffers... oh well!
You can, of course, copy around *pointers* to them. This means you have
to dynamically allocate them. If you want to be able
to create events in
a real-time thread, you will have to get into more advanced C++ and make
a custom allocator for that etc. etc.
Pointers: That's exactly what I'm doing... and I do need to dynamically
allocate them too... so I decided to do that in a non-RT thread, and have a
ringbuffer of new events, and a ringbuffer of valid events, where the JACK
RT thread can pull one of the Events from the "store" of new events, and
then fill it in in a RT context, and then push that pointer onto the other
ringbuffer that's going to be processed in another non-RT context... It
might be a little more complex than needed, but its serving my purposes now
:)
Passing strings around isn't possible due to the nature of strdup(), so I've
enumerated all the messagesthat the JACK thread might need to send, and then
have a big switch to handle all the different error messages. Not very nice
but its RT safe. I've done the same for sending the PATH and SIGNATURE
elements of OSC messages.
Functors & closures, yeah I suppose... for now this system is working, and
quite easy to add new types to (does need a big recompile after a change
though.. as heaps of headers include the "Event" type, as its pretty much to
core of the Engine.. :)
-Harry
PS: Nice article on "Duct tape programming":
http://www.joelonsoftware.com/items/2009/09/23.html Especially read the
paragraph beside the photo of the guy jumping
2 Sep
2 Sep
10:36 a.m.
On 09/01/2011 10:37 PM, Harry van Haaren wrote:
Functors & closures, yeah I suppose... for now this system is working,
and quite easy to add new types to (does need a big recompile after a
change though.. as heaps of headers include the "Event" type, as its
pretty much to core of the Engine.. :)
Hmm, i used Functors and Closures in jass for passing commands to the
realtime thread and wrote a small article about it.
http://178.63.2.231/~tapas/wordpress/?page_id=45
Coupled with a poor man's garbage collection scheme using
boost::shared_ptr's this was a quite quick way to hack up jass. There's
no need to introduce new types if you want to do something new. Actually
there's only exactly one type that gets passed through the command
ringbuffer and that is boost::function<void(void)>. See e.g.
https://github.com/fps/jass/blob/master/engine.h
and
https://github.com/fps/jass/blob/master/main_window.h
I agree that this method doesn't necessarily scale to other kind of
applications and it also might be a bit more error prone than a well
thought out event system using types that cover all bases, it does make
for a quite good solution for an app of the scope of jass..
Have fun,
Flo
-Harry
PS: Nice article on "Duct tape programming":
http://www.joelonsoftware.com/items/2009/09/23.html Especially read
the paragraph beside the photo of the guy jumping
Taking a look..
1:59 p.m.
On Fri, Sep 2, 2011 at 9:36 AM, Florian Paul Schmidt <mista.tapas(a)gmx.net>wrote;wrote:
Hmm, i used Functors and Closures in jass for passing
commands to the
realtime thread and wrote a small article about it.
Cheers for the link, I've browsed it before I think, consider yourself
"blog-famous" :D
Indeed the functor system will work, but I find the syntax quite clumsy,
and I don't want the GUI to become non-responsive until the Engine signals
the event is done. Reason for this is that there's quite an amount of events
going back and forth, and I estimate the GUI will become too laggy to feel
right.
While I could do some (nasty) event checking and not in general, only
blocking when I know I'm changing the state of an EngineElement that I need
a reference to. Again quite nasty IMO. The other problem is that since all
communication is OSC, I cannot guarantee that all "controller" or
"view"
programs (ie OSC senders / receivers) will comply. So I need a "foolproof"
plan, where *any* messages can be sent in *any* order, without crashing /
hiccups.
Your mention of "poor man's garbage collection" is quite a do-able system,
and I like how it automatically abstracts the non-RT actions away from the
RT thread. (ie: removing samples from mem etc) Will let you know if I ever
get around to doing it... Currently I'm just storing all samples ever used
in mem... and praying somebody doesn't load a 2GB .wav file :D
<http://www.codeproject.com/KB/cpp/fastdelegate2.aspx> for example.
(I used Don's original "Fastest Possible C++
Delegates" on an embedded
project years ago -- worked great).
Nice article there... seems a clean enough implementation. Perhaps if I
decide a on a rewrite of the event handling at some state I'll concider this
as an option :)
-Harry
5:13 p.m.
On Fri, 2011-09-02 at 10:36 +0200, Florian Paul Schmidt wrote:
On 09/01/2011 10:37 PM, Harry van Haaren wrote:
[...]
Coupled with a poor man's garbage collection
scheme using
boost::shared_ptr's this was a quite quick way to hack up jass. There's
no need to introduce new types if you want to do something new. Actually
there's only exactly one type that gets passed through the command
ringbuffer and that is boost::function<void(void)>. See e.g.
Careful doing this, note that dropping the last shared_ptr to an object
is NOT real-time (it calls delete), even if destroying the actual object
is.
-dr
7:29 p.m.
On 09/02/2011 05:13 PM, David Robillard wrote:
On Fri, 2011-09-02 at 10:36 +0200, Florian Paul
Schmidt wrote:
yeah. that's why there's a extra reference stored in a list whenever an
(disposable) object is created.. This list is traversed periodically
from within the GUI thread to check whether any one's object refcount
has dropped to 1 (not 0) and only then is that last reference removed
from the list causing the ref count to go to 0 and the object finally
being deleted (in the GUI thread)..
Note that all objects the engine manages in jass are stored in
disposable<T> which forces them to be allocated through the factory
function that always stores an extra reference in the list..
Regards,
Flo
On 09/01/2011 10:37 PM, Harry van Haaren wrote:
[...]
Coupled with a poor man's garbage collection
scheme using
boost::shared_ptr's this was a quite quick way to hack up jass. There's
no need to introduce new types if you want to do something new. Actually
there's only exactly one type that gets passed through the command
ringbuffer and that is boost::function<void(void)>. See e.g.
Careful doing
this, note that dropping the last shared_ptr to an object
is NOT real-time (it calls delete), even if destroying the actual object
is.
4:29 a.m.
On 09/01/2011 01:18 PM, David Robillard 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?
-gabriel
5:22 p.m.
On Thu, 2011-09-01 at 21:29 -0500, Gabriel Beddingfield wrote:
On 09/01/2011 01:18 PM, David Robillard wrote:
Because it uses inheritance, this object is not POD, so strictly
speaking no.
-dr
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?
6:03 p.m.
On Fri, Sep 2, 2011 at 10:22 AM, David Robillard <d(a)drobilla.net> wrote:
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.
-gabriel
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?
6:29 p.m.
On Fri, 2011-09-02 at 11:03 -0500, Gabriel Beddingfield wrote:
On Fri, Sep 2, 2011 at 10:22 AM, David Robillard
<d(a)drobilla.net> wrote:
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
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?
4825
days inactive
4840
days old
linux-audio-dev@lists.linuxaudio.org
25 comments
7 participants
participants (7)
-
Arnold Krille -
David Robillard -
Florian Paul Schmidt -
Fons Adriaensen -
Gabriel Beddingfield -
Harry van Haaren -
Paul Davis