Re: Python plugin API locking (patch)

[Marko Kreen <marko@l-t.ee>]

On Sat, Oct 04, 2003 at 06:51:16PM +1000, Peter Zelezny wrote:
> On Sat, 4 Oct 2003 01:18:33 +0300
> Marko Kreen <marko@l-t.ee> 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...
> 
> Strictly speaking, plugins shouldn't access xchat's gtk main loop.
> You shouldn't use any of xchat's libraries, open/link your own. The
> practicalities of this might be problem though.

PyGTK seems like 'killer usage' for python plugin.  And afaik
you cant have several instances of libgtk.so active in one
process...

> When you come to a consensus on which patches should be applied
> to python.c, let me know :)

Now I thought a bit and I still recommend applying the 'locking
fix patch'.  This should fix all locking problems with python
plugin and gives "full-blown" threading with only caveat:
"Iff you use PyGTK, you MUST call BOTH xchat.* funtions and GTK
signal-loop functions (like gtk.mainloop, dialog.run) only from
main thread."

IMHO this is an easy requirement to keep, so as python.c cant
do better without support from xchat core, thus I decided to be
content with such state :)

As G. Carneiro also OK'd it then its consensus?

So I recommend to commit 3 patches:

* unload bug fix
* argv bug fix
* locking fix

I dont know what release schedule main xchat has, but FYI:
those three patches fix all known problems possible to fix
in current python.c architecture.

The 'import gtk' bug needs architecture change (change is good
on several other reasons too) so next patches either from me or
Gustavo Carneiro to python.c will be major reorgs.

> P.S Please check the HACKING file for coding style if you want to patch
> plugin.c (I don't care about python.c coding style).

About plugin.c locking: I would like to see it, less worries in python.c.
Ofcourse, if now other plugins (perl/tcl/?) say they definitely
will never do threads, then it may be pointless.  What are the
plans there?

About xchat/gtk reentrancy problem: I guess plugin threading is
not enough argument to fill xchat core with locking.  Are there
any plans to make xchat core multi-threaded on some day?

-- 
marko

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