X-Chat not threading?
Ziggy SpaceRat
I wonder if X-Chat is using multi-threading or not...
I noticed that no other IRC-client is that easy to freeze as X-Chat...
...and this is true for the Windows and Linux-version of X-Chat...
A stalled DCC makes X-Chat freeze...
... a highly lagged server makes X-Chat freeze...
... problems connecting to a bouncer make X-Chat freeze...
In all these cases X-Chat returns back to useability as soon as the
condition that caused X-Chat to become unresponding ends or gets
interrupted for some time.
As a workaround for stalled DCCs, I set the DCC stall timeout pretty
low, to reduce the time X-Chat does not respond. For server connection
trouble, there appears to be no workaround, except waiting for X-Chat
to become responsive for a short time again and then /DISCON the
trouble-making server.
Could it be that X-Chat doesn't use multi-threading at all, due to
its Linux-heritage, as to my knowledge Linux threads like sh*t?
Well, my point is that this behavior of X-Chat is the last real
annoyance left.
A huge lag on DALnet shouldn't make the whole client freeze... neither
should a hung DCC transfer.
It would be great if this could be solved some day...
--
Bye
Ziggy SpaceRat
--
XChat-discuss: mailing list for XChat users
Archive: http://mail.nl.linux.org/xchat-discuss/
Michael Edenfield
> Hi Group!
>
> I wonder if X-Chat is using multi-threading or not...
>
> its Linux-heritage, as to my knowledge Linux threads like sh*t?
X-Chat uses threads only in the simplest sense. Essentially, each
server connection gets spawned inside a thread. It's VERY easy to block
X-Chat, just do an /exec or /dns on something that takes a long time.
I've got the early workings of a multi-threaded revamp of the xchat
internals, but it is a huge amount of work. As Peter pointed out,
there's plenty of much more low-hanging fruit in the bug tracker that
these stalling problems, and adding threadability which is still stable
under all the plugin and script combinations is tricky.
There's also the issue of getting a portable threads library. As you
mention, Linux threads aren't anything to write home about. The BSD's
have god knows how many thread libraries between them all (FreeBSD has 3
all by itself). And Windows threads API isn't even pretending to be
POSIX compliant.
It's one of the major things about X-Chat I would like to help 'fix' but
the work is immense, and will require volumes of beta testing, so I
would expect to see most of the other bugs fixed and the existing
product as solid as possible before a change that big gets undertaken.
--K
Dan
Why would you need threads? All input/output and dns lookups can be achieved
in nonblocking ways.
Dan
Michael Edenfield wrote:
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
Jan Knutar
> Why would you need threads? All input/output and dns lookups can be
> achieved in nonblocking ways.
I've understood nonblocking lookups are nearly impossible to do in a
portable way :/ Doesn't xchat fork for host lookups anyway? Threading
in a way, I guess.
Richard Fuchs
Ziggy SpaceRat wrote:
> Could it be that X-Chat doesn't use multi-threading at all, due to
> its Linux-heritage, as to my knowledge Linux threads like sh*t?
xchat is indeed not a multi-threaded application, but not because "linux
threads like shit". the problem with threads under unix in general is,
that there is no single native api for threads that's implemented on all
unixes. there's posix threads, which is not a very good api and more
importantly not available on all platforms.
however, it is perfectly possible to create applications which never
"hang" for even a fraction of a second with only a single thread. it's
all a matter of coding practice. xchat becomes unresponsive not because
it's not multi-threaded, but because some parts of the code are not well
written. this can also include code not part of xchat itself, but code
imported from libraries (e.g. the dns lookups from glibc). in this case
however, it's the responsibility of the application to work around this
behavior from lib code. this can be quite cumbersome and/or prone to
bugs though, so sometimes the unresponsiveness is simply the result of
laziness...
cheers
richard
Peter Zelezny
Ziggy SpaceRat <Ziggy.S...@gmx.de> wrote:
> I noticed that no other IRC-client is that easy to freeze as X-Chat...
> ...and this is true for the Windows and Linux-version of X-Chat...
>
> A stalled DCC makes X-Chat freeze...
> ... a highly lagged server makes X-Chat freeze...
> ... problems connecting to a bouncer make X-Chat freeze...
This is news to me.
> In all these cases X-Chat returns back to useability as soon as the
> condition that caused X-Chat to become unresponding ends or gets
> interrupted for some time.
>
> As a workaround for stalled DCCs, I set the DCC stall timeout pretty
> low, to reduce the time X-Chat does not respond. For server connection
> trouble, there appears to be no workaround, except waiting for X-Chat
> to become responsive for a short time again and then /DISCON the
> trouble-making server.
>
> Could it be that X-Chat doesn't use multi-threading at all, due to
> its Linux-heritage, as to my knowledge Linux threads like sh*t?
Threads shouldn't be necessary for this stuff, if all the callback
routines are kept short and nonblocking. Maybe you should describe these ways
of locking it up in more detail, because I've never actually seen it.
> Well, my point is that this behavior of X-Chat is the last real
> annoyance left.
> A huge lag on DALnet shouldn't make the whole client freeze... neither
> should a hung DCC transfer.
Nope it shouldn't, and actually it doesn't for me :)
Maybe there are some portability issues with the non-blocking sockets,
that act differently on your OS.
You could also run xchat in GDB and hit ctrl-c when it locks up,
hopefully that'll show us which function it's getting stuck in.
--
Peter.
Peter Zelezny
Michael Edenfield <kut...@kutulu.org> wrote:
> > I wonder if X-Chat is using multi-threading or not...
> >
> > Could it be that X-Chat doesn't use multi-threading at all, due to
> > its Linux-heritage, as to my knowledge Linux threads like sh*t?
>
> X-Chat uses threads only in the simplest sense. Essentially, each
> server connection gets spawned inside a thread. It's VERY easy to block
> X-Chat, just do an /exec or /dns on something that takes a long time.
/exec and /dns both fork a new process, so they won't block. The only
way it'll block "a bit" is if the /exec'ed process sends alot of data
back to the parent, causing it to display alot of text. This is pretty
rare though.
[snip]
> It's one of the major things about X-Chat I would like to help 'fix' but
> the work is immense, and will require volumes of beta testing, so I
> would expect to see most of the other bugs fixed and the existing
> product as solid as possible before a change that big gets undertaken.
I would try to fix the actual reason for the lockups first, which don't
seem to be lack of threading. I'm starting to suspect a badly behaving
script or plugin.
--
Peter.
Michael Edenfield
> On Friday 02 January 2004 02:26, Dan wrote:
> > Why would you need threads? All input/output and dns lookups can be
> > achieved in nonblocking ways.
>
> I've understood nonblocking lookups are nearly impossible to do in a
> portable way :/ Doesn't xchat fork for host lookups anyway? Threading
> in a way, I guess.
Yes, this is how /dns currently works. It exec's "nslookup" or "host", but
there are two problems with that:
1) X-Chat is otherwise completely portable to other OS's, like Windows,
but Windows has no fork() call. It does have exec*() calls, but those
really should be relegated to actually executing something.
2) The sockets library has perfectly valid, useful, and flexible
functions for doing DNS lookups built right in. Launching an external
application just to execute getaddrinfo() is stupid.
Doing non-blocking I/O and lookups is how things used to get done before
people knew how to write threads. Internally, operating systems *use*
threads to simulate non-blocking I/O. Threads are a modern, efficient,
accepted way to write scalable programs, and there is an established
POSIX standard for how to write them. (Of course, you have to bolt
libraries on top of Windows to get that standard, but that's not any
different from gtk or whatnot.)
There's no good reason *not* to use threads, even if you just slap
libc_r ontop of your app to get fake threading, other than the amount of
work required. Which is substantial, but IMHO, worth it.
--K