[Icecast-dev] Updated version of patch

Michel Van den Bergh michel.vandenbergh at uhasselt.be
Wed Sep 10 00:57:21 PDT 2008

>This is in subversion now. I'll try to get a new release out this
>weekend. Thanks!


But I noticed that giving up the global interpretor lock
in a few functions allows other threads to do something stupid (like 
the shout object during a write).

So for everything to be absolutely thread safe a python shout object
should contain a mutex and there should
be appropriate locking around accesses to s->conn.

It is a little hard to figure out precisely at what places
locking would be needed.

The safest method I could think off  is simply to include
thread safe versions of the shout api functions which
have a shout_t as its first argument. For example

int shout_set_host_safe_ts(shout_t *self, char* host, pthread_mutex_t 
  int ret;
  pthread_mutex_lock (mutex));
  pthread_mutex_unlock (mutex));
  return ret;

One should then use the thread safe version instead of the original api 

To avoid mistakes I would generate these definitions automatically from 
shout.h using
a small python program.

What do you think?


Brendan Cully wrote:
> On Saturday, 30 August 2008 at 16:00, Michel Van den Bergh wrote:
>> Attached is a patch against shout-python-0.2 which does two trivial but  
>> very useful things
>> (1) The function "get_connected" is exported so that shout-python becomes 
>> usable
>> in nonblocking mode. In the current version of shout-python "open"
>> raises an exception in nonblocking mode.
>> (2) The global interpreter lock is released in the potentially blocking
>> functions "open", "send" and "sync".  In this way a shout-python can run  
>> in blocking mode
>> in a separate  thread without blocking other threads.
>> Both parts were tested.
>> I needed either (1) or (2) to make a webgui for controlling an icecast  
>> source. I tried both approaches. They both work but in the end I opted for 
>> (2) since the code was cleaner.

More information about the Icecast-dev mailing list