Re: [Licq-main] Licq 1.02 blocks indefinantly in MintorSockets_tep

[Rick B. <Rick@BigScaryChildren.net>]

On Mon, 26 Feb 2001, Graham Roff wrote:

> > So Licq requires kernel threads now then, right?  NetBSD, and many other
>
> Any multithreaded version of Licq uses kernel threads in some way I
> guess...I'm not totally sure how LinuxThreads work, they are pretty fucked
> up if you ask me.  Each thrad actually runs as a seperate process and the
> kernel just forges some shared memory stuff...

Yeah, linux threads are kinda hackish.  It works, but its inefficient
compared to user-level threads or a hybrid thread architecture like
Solaris has.  One of the disadvantages (or benefits) to using NetBSD over
Linux is that they'd rather not implement a feature (i.e. kernel threads)
than implement it poorly (i.e. LinuxThreads).

> > Is there a lot of code that calls syscalls which may block, or is it well
>
> I believe that in Licq itself the blocking code is just the MonitorSocket
> call to select() that blocks.  Qt itself has a blocking routine though,
> something having to do with X events blah blah blah.  I'm not sure what to
> do about that...

Hmmm. Ok, when I get some time (how the hell do you find the time to do
school and manage Licq?  I have almost no time and I thought UW C.Eng. was
supposed to be more work than UW CS!)  I'll write a syscall jacket so
that the whole process doesn't get blocked in select etc.  I doubt the
blocking Qt calls will be a problem - they probably aren't stuck in the
kernel.

Thanks,
	Rick

----
Rick Byers
University of Waterloo, Computer Science