[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
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
One should then use the thread safe version instead of the original api
To avoid mistakes I would generate these definitions automatically from
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
>> 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