[LAD] Looking for an introduction to rt programming with a gui

fons at kokkinizita.net fons at kokkinizita.net
Mon May 24 09:04:18 UTC 2010


On Sun, May 23, 2010 at 06:58:42PM -0400, Paul Davis wrote:

> clearly, you've not used shared_ptr.

I'm not using them, for various reasons:

1. Looked at the documentation and decided I didn't want
this. Have you counted the number of caveats ? Just using
an unnamed shared_ptr as function argument can be enough
to invalidate the whole thing.

2. At least in the type of apps I write (DSP, RT), memory
management should IMHO be explicit. Without that, you don't
even have any idea if how much memory your code is using at
any time, nor when some of it will be freed - it could very
well happen at an unconvenient time. If you have to keep 
copies of a smart pointer just to make shure it won't call
delete[] while in a RT context, then the whole point is lost.

3. I use C++, and all classes I write are designed to clean
up after themselves, just as all threads are designed to 
terminate themselves explicitly and cleanly. Making sure 
that these things are correct takes some work, but the
reward is a level of confidence I wouldn't have with any
'automated' way of doing this. It also forces you to _think_
about these things, which results in cleaner design.

4. In those cases where dynamically allocated objects 
move around between objects or threads and it's not
clear who should take care of managing them, very often
following some simple rules solves the problem. For
example, the message objects used by clthreads are in
their basic form not even reference-counted. The rules
for using them  are simple: when you receive one, or 
create one, you own it. After use, either delete it
or send it to some other thread, and in boht cases 
assume it doesn't exist anymore. 

> i am glad to hear, however, that you've never used longjmp/setjmp in your
> code, or thread local storage.

I *do* use setjmp/longjmp in one case, when interfacing with
libpng which uses them for error recovery.

I've never understood what's the point about the horrible 
thread local storage API. All threads I use are C++ objects,
any non-static data members of such a class are local to the
thread. That's all I need. You need to bootstrap thr_start()
via a static C function once (using the void *arg as object
pointer) and that's it. You could do the same in plain C as
well, just putting all thread local data into a struct.

Ciao,

-- 
FA

O tu, che porte, correndo si ?
E guerra e morte !



More information about the Linux-audio-dev mailing list