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