Re: Python plugin API locking (patch)

[Peter Zelezny <zed@xchat.org>]

On Tue, 7 Oct 2003 14:09:29 -0400
Michael Edenfield <kutulu@kutulu.org> wrote:

> > > My main problems are twofold: 1) I dunno if it would even be accepted
> > > into the main source tree, and 2) it makes no sense to use Windows
> > > threading for Windows and POSIX threading for everything else.  There
> > > are pthread libraries for Windows, or I would probably work up some kind
> > > of compatibility headers (tcl, python, etc. all have to do this as
> > > well), but I don't have nearly as much POSIX threading experience as
> > > Windows threading experience.
> > 
> >   IMHO, glib thread abstraction is the way to go:
> > 	http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html
> > 
> >   Regards.
> 
> Yes, I actually just found this when looking back over the recent Python
> locking issues.  And it's exactly what I was looking for to get started.
> I'm working on my first lock: a simple mutex lock on the output buffers
> for sessions, to allow multiple threads to hold a session reference and
> write output later on.  If that goes smoothlyI will have a better idea
> how much effort, and how disruptive, locking in general would be.

I don't want to discorage you or anything, but wouldn't the time be
better spent on other things? Why does xchat need to be thread safe
(besides for use with PyGTK), and will the average user even notice the
change after this huge work has been done?

Just look at the feature requests tracker, "thread safety" is hardly a
concern :)

-- 
Peter Zelezny.
--
XChat-discuss: mailing list for XChat users
Archive:       http://mail.nl.linux.org/xchat-discuss/