Re: Python plugin API locking (patch)

[Michael Edenfield <kutulu@kutulu.org>]

* Marko Kreen <marko@l-t.ee> [031003 18:25]:
> On Fri, Oct 03, 2003 at 10:34:41PM +0100, Gustavo J. A. M. Carneiro wrote:
> >   This patch should protect all plugin API functions with a global
> > recursive mutex.
> 
> Thats a cool patch, but it seems its not enough...
> 
> You protect plugins from each other, thats cool, but at the
> moment plugin can run gtk signal loop, its not enough: now also
> xchat C code should go through locks, that means that locks
> should be in xchat core code.  Thats what made me so worried...
> 
> (Think of one thread having plugin lock and calling xchat
> functions, another thread running gtk.mainloop - now there
> are 2 threads inside xchat core)

The correct solution (the only one that I think will work completely) is
to ultimately lock *resources* at a low level.  The locks need to be, as
you said, placed throughout the XChat core code.  The code needs to lock
thinks like output buffers and global data lists, not whole plugins.

The benefits of this are obvious: not only does it remove much of the
locking issues with plugins, but it permits the code code itself to
thread more.  Right now a single thread is spawned per server and that's
basically it.  For example, the optimal way to do a dns lookup is to
spawn a dns lookup thread -- but that requires locking the output
buffers on the sessions.

The downside, of course, is that it's a *ton* of work.  But the locking
itself can be done piecemeal.  Chase down global resources and start
adding locking code to them one at a time.  Having seen other
applications go through this (and been writing some of them), it's a
pain in the ass.  But ultimately it's the only way to do it right.

(BTW: I'm doing this for the session output buffers in my local copy
right now, to implement a working internal dns lookup.  Obviously it
will have to work *flawlessly* before there's any chance of it getting
accept into the base code, if at all.)

--Mike

PGP signature