Re: Python plugin API locking (patch) [Perl/TCL also]

[Peter Zelezny <zed@xchat.org>]

On Mon, 6 Oct 2003 15:29:35 +0300
Marko Kreen <marko@l-t.ee> wrote:

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

I suppose that's the only problem then, PyGTK bypasses the xchat_*
functions and jumps straight into xchat's core via gtk signals.


> 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 :)

Yeah I think that's a perfectly fine requirement. XChat core does this
itself, when doing a DNS lookup. The child process (thread on win32) only
sends the results down a pipe, and the parent makes functions calls and
changes the structs.


> 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'll be applying these then:

789 python-argv.diff
13351 python-locking.diff
607 python-unload-hook-fix2.diff


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

No release plans at this stage, it'll be pretty quiet for a while.

http://sourceforge.net/tracker/index.php?func=detail&aid=686792&group_id=239&atid=100239
http://sourceforge.net/tracker/index.php?func=detail&aid=755301&group_id=239&atid=100239
http://sourceforge.net/tracker/index.php?func=detail&aid=772596&group_id=239&atid=100239

I suppose the patches fix only the last two bugs there?


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

You'll have to ask the perl/tcl authors, I think they're subscribed here,
let's see if they jump in.



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

No, there really is no need to use any threads in xchat itself.


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