Re: Python plugin API locking (patch)

[Michael Edenfield <kutulu@kutulu.org>]

* Gustavo J. A. M. Carneiro <gjc@inescporto.pt> [031006 07:03]:
> A Dom, 2003-10-05 ?s 16:45, Michael Edenfield escreveu:
> > 
> > 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.
> 
>   While running under gdb, I have never even noticed xchat spawning
> threads.  Are you sure xchat core uses threads at all?

I'm only working with Windows at the moment, and yes it quite clearly
runs CreateThread once per socket.  IMHO this is the correct way to
handle things in general, since pretty much every modern OS supports
threads of some sort (even if it's just libc_r).  

> 
> > 
> > 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.
> 
>   Yes, I agree with you, but I'm not willing to do the huge amount of
> work to get this right.  Especially since I don't understand at all the
> xchat internals, since I was looking at the code for the first time.

I'm willing to do the huge amount of work, though it will obviously take
a huge amount of time :)

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.

The end result is, I'm not sure it's worth working on this instead of
trying to fix some of the gtk or glib caused problems first.  Thus the
reason I'm dragging my feet even getting started.

--Mike

PGP signature