On Thu, 2002-03-07 at 19:18, Gustavo Niemeyer wrote: > Alex, I think you missed the point here. It's not about converting the > string, but *not* converting it. This channel->context list attribute we're > talking about is a pointer to a struct, flaged as a string, so you must > *not* convert it to a string, otherwise you may crash xchat. You're right. I missed the point. Sorry... Why is it tagged as a string if it's actually a struct? > > Uh... I've been using native threads in my Java code for quite some time > > Please, notice I'm not the known python interface maintainer. I'm > working on a new interface, developed from the ground. Oh, okay, then please consider that statement to mean that it's possible to use native threads safely. ;) By the way, I'm not 'the known' Java interface maintainer, either. I do hope to get my code rolled into X-Chat 1.9.x once I've finished it, though. (Zed? Are you reading this?) > > now, on X-Chat 1.8.x. I put in accesses to X-Chat functions and data in > > a queue which is run several times per second in the main X-Chat thread. > > The calling thread is blocked until the queue item is handled, at which > [...] > > I suggest you consider using such a queue for your thread support, if > > X-Chat still isn't thread-safe, to avoid any synchronization problems. > > I'm currently using a simple lock scheme, protecting commands from > being run out of time. I don't think this is going to be a problem, but > if this turns out to be a bad option, I'll consider your suggestion for > sure! It's nice to share ideas with other interface developers. What do you mean by 'out of time' ? What happens when the commands _are_ run out of time? 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