[ previous ] [ next ] [ threads ]
 To :  yate@v...
 From :  Allan Sandfeld Jensen <linux@c...>
 Subject :  Re: [yate] Patch storm
 Date :  Mon, 14 Jun 2010 09:26:04 +0200
On Friday 11 June 2010, Paul Chitescu wrote:
> Some patches have problems in other usage scenarios than you are using them
> so we need to modify or reject them. For example the
> 0007-Use-realloc-in-String- append patch can cause crashes or abnormal
> results in code like:
> String a = "abc"; a += a;
Well, there is a theoretical risk because YATE is missing a "String 
opertor+=(String)" function, and String has the defined the typecast operator 
to "const char*". If the you use the operator+ (String, String) instead, then 
that function will take the copy that is needed to make the operation safe.

Btw, please note that the append operation is done in a fashion that makes it 
read-safe even from different threads. This is very carefully written code 
(not safe across mulitple threads writing though, but neither are the old 
String classes).

> Other patches my not be portable across all architectures or need
> alternative implementation - the 0004-Check-mutex-error is part of this
> cathegory. Mutexes are different in Windows and some functionality like
> EBUSY is not supported on all *BSD platforms.

Are you sure? I know I have tried myself, but currently the patch is only 
useful on non-linux platforms. Linux has the phtread_mutex_timeslock, so that 
code is no longer used there. All the BSDs and even Windows have AFAIK been 
POSIX certified and EBUSY return from a pthread_mutex_trylock is the central 
defined baviour of that function. It should work in every implementation, 
unless the implementation is really broken.

> We will apply most of the functionality enhancements, especially those that
> are not influencing existing installations.
> About performance enhancements - although it's obvious from the code that
> it can be improved in this direction, profiling Yate doesn't show it would
> benefit a lot from them so we prefer to keep the code easy to understand
> as much as possible. There performance bottlenecks are pretty obvious and
> we are fixing them whenever possible. Valgrind is a great tool :-)
> Finally, there are some patches introducing quite substantial changes that
> need more analysis. Stay tuned, we will continue to reply to this thread
> with the progress and any feedback.
Thanks for looking through the patches. I greatly appreciate any feedback and 
will happily answer any questions

Best regards