[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: threads
From:       Waldo Bastian <bastian () suse ! de>
Date:       1999-12-03 17:16:19
[Download RAW message or body]


> Summary:
> ========
> 
> Its basically impossible to get pre-emptive multithreading reliable.
> 
> Cooperative multithreading is an option. The benefit is that it is much 
> easier to program a worker thread than QTimer beased state machine. The 
> disadvanatge is that calls like fopen() still block. 
> 
> The other option is to use processes as we do with the io_slaves. The 
> disadvantage here is that it requires more memory and the IPC is somewhat 
> slower. The advantage is that a dying io_slave doen't crash your application.
> 
> 
> Discussion:
> =========
> 
> In theory you can do cooperative multithreading toghether with 
> kernel-threads.  Whenever you are about to enter a possible-blocking system 
> call, you use a kernel-thread for this. This way you can make it that you 
> keep the semantics of cooperative-multithreading but you don't have the 
> disadvantage of blocking on system calls.
> 
> (A quick & dirty way to get this behaviour is to use kernel-threads and lock 
> a mutex all the time except for when you are about to enter a system call.)

Following up on myself:

A quick investigation of some Threading-FAQs seems to indicate that there is no
"portable non-preemptive non-blocking threads library". 

* Pth is portable an non-preemptive but can block.
* pthreads is portable and non-blocking but is preemptive.
* It might be possible to get non-preemptive non-blocking behaviour on 
commerical Unices by specifying some smart thread-priorities but this is not 
portable and possibly not save on multi-processor systems.

What else can we do: Crippled POSIX threads.
======================================

We could use pthreads and cripple it to get non-preemptive behaviour. We lock a 
mutex and only when we explicitly want to allow concurrency we unlock the 
mutex. 

* This means that whenever Qt goes to sleep on it's select() to wait for an 
event, it should unlock the mutex and lock it again when it wakes up from the 
select.

* Threads can unlock the mutex whenever they are going to do some dangerous 
(read: possibly blocking) system calls / library call and lock it again when 
they return.

I guess that the Troll's don't want to make Qt dependant on threads, so for 
this to work, QApplication should call a virtual function whenever it is about 
to call select and call another virtual function after select has returned.

Cheers,
Waldo

[prev in list] [next in list] [prev in thread] [next in thread]