On Sat, 2002-03-09 at 08:19, Gustavo Niemeyer wrote: > Weren't you talking about this when you told me about your "queue > system"? XChat is not thread safe, so one may not assume so when working > with threads. By running "out of time", I meant to run xchat functions > (any of xchat_*) when xchat is doing something else. To protects agains > this, I've created an xchat lock. Whenever a plugin tries to access some > of xchat's functions, it acquires this thread. If xchat is doing > something else, the thread blocks. Then, when xchat passes the control > to the plugin, it releases this lock, and acquires it back before > returning. This system also ensures that two xchat functions are not > going to be executed at the "same" time. Sounds pretty similar to my queue system. The only disadvantage that I can see is that you can't force only a few things to happen every cycle. If any Python code wants to lock up X-Chat, it simply waits until the lock is released in the next cycle, and then runs an infinite loop. The function in your plugin, that releases the lock so Python code can run, would never return and return control to X-Chat, and X-Chat would lock up. With my queue system, only a certain number of queue events get run each cycle, and each queue event consists of code that is trusted (ie, I wrote it, not the author of the Java plugin, which cannot generate queue events directly). Therefore, Java code can never force X-Chat to lock up. The worst it can do is hog lots of CPU and slow things down, but since all of the threads that are running untrusted code have a decreased priority, the user can still quit X-Chat cleanly and remove the offending plugin. Regards, Alex. -- PGP Public Key: http://aoi.dyndns.org/~alex/pgp-public-key -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS d- s:++ a18 C++(++++)>$ UL+++(++++) P--- L+++>++++ E---- W+(+++) N- o-- K+ w--- !O M(+) V-- PS+++ PE-- Y+ PGP+(+++) t* 5-- X-- R tv b- DI D+++ G e h! !r y ------END GEEK CODE BLOCK------
This is a digitally signed message part