[Icecast-dev] Updated version of patch

[Michel Van den Bergh]

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

Thanks!

But I noticed that giving up the global interpretor lock
in a few functions allows other threads to do something stupid (like 
deleting
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 
*mutex){
  int ret;
  pthread_mutex_lock (mutex));
  ret=shout_set_host(s->conn,host);
  pthread_mutex_unlock (mutex));
  return ret;
}

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

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


What do you think?

Regards,
Michel






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.
>>