Re: [Ekiga-list] PTLIB alsa plugin status

[Derek Smithies <derek indranet co nz>]

Hi,
On Wed, 25 Feb 2009, Alec Leamas wrote:
> Hi :-)
>
> Thanks for this info!   As you state, this should work as long as they are 
> instantiated  in a proper way. And it's simple just to add some assertions to 
> make sure that this is indeed the case.
>
> I still don't get why the device pointers needs locking. Is the overall Ekiga 
> design such as there are several  threads writing concurrently?  Or is this a 
> general requirement for the driver, for other scenarios the Ekiga? In other 
> words , is the PTlib alsa driver defined as reentrant?
yes, the ptlib alsa driver needs to be reentrant.

One thread could attempt to close the audio device while a second thread 
is reading/writing data from/to the alsa system.

It is not the overall Ekiga design that sets the requirment for coping 
with multiple threads - it is a the PTLib/OPAL design that sets the 
requirement for coping with multiple threads.

The discussion topic of threads and too many threads and so on has 
occuppied many hours at conferences, and many emails, and is slightly 
tedious. A useful article on threads is found at:
http://www.gotw.ca/publications/concurrency-ddj.htm

In my view, the reason many programmers argue vehemently against threads 
is a combination of several factors
 *all their early programs were single threaded (e.g. hello_world) and so
   they developed the mindset of only knowing how to cope with 1 thread.
 *some programming styles (which are spaghetti like in nature) are torture
   to debug when threaded
 *many of the open source tools (in particular debuggers) don't handle
   threads well and make the whole code&fix process too hard

However, ptlib and opal are coded to a high degree of quality. There are 
still issues (device plugins) but these are getting fewer and fewer. Given 
the nature of voip and how voip works, I don't think any other model would 
work.
 Remember that opal is a library, and is used by people making hundreds of 
simultaneous calls. If you do propose a different way of doing things, 
will the new architecture cope with being scaled up?

Derek.
 -- 
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derek indranet co nz
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/