[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: zed: When will the new PI be done?
[...]
> Why is it tagged as a string if it's actually a struct?
You may check Peter's position in one of his answers.
> > > 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. ;)
Thanks! ;-)
> 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?)
Got it..
> > 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?
You never know... that's the point. :-)
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.
--
Gustavo Niemeyer
[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
--
XChat-discuss: mailing list for XChat users
Archive: http://mail.nl.linux.org/xchat-discuss/