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

List:       kde-devel
Subject:    Re: KDE and IO
From:       Sirtaj Singh Kang <ssk () physics ! unimelb ! edu ! au>
Date:       1998-11-30 4:16:12
[Download RAW message or body]


On Sun, 29 Nov 1998, David Sweet wrote:
[snip]
> I've thought about this a little.  Why not create a class derived from 
> QObject which has virtual methods  start()/end()  which, when
> reimplemented turn off/on (respectively) the GUI widgets which cannot
> be used during a given blocking IO process.
> This class, after a call to start() would set up a QTimer to process
> GUI events every n milliseconds.  end() would turn off the QTimer.

This won't work, since afaik QTimerEvents are added to the Qt event queue
just like other events, so the timer events won't be processed till the
app enters the event loop (ie exec or process*Event).

The "best" way to do non-blocking IO on unix without threads is with a
traffic state machine and a socket notifier, ie respond to read and write
events from the notifier. Unfortunately, this becomes hairy very quickly
if there is a lot of 2-way traffic and the protocol is of a fairly high
level (eg sendmail or pop3). 

Ideally we'd have a library of non-blocking IO classes for high-level
protocols like the (blocking) mimelib, eg the client code initiates IO
with commands like "getMessageBody( const char *messageid )" and responds
to signals like "authRequest()" and "messageBodyReceived()"  etc.  But
somebody has to write it. :) kioslave is similar to this but a separate
process isn't usually necessary.

IMHO, threads are out of the question for now; they're tricky to get
working with Qt, and most people I know don't have a thread-safe X11.

-Taj.

Sirtaj S. Kang       taj@kde.org         ssk@physics.unimelb.edu.au
School of Physics    Univ of Melbourne   KDE: The Desktop sans Toga

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