fam
[Top] [All Lists]

Re: [fam] Qt/GTK+ tutorial

To: bastian@xxxxxxx
Subject: Re: [fam] Qt/GTK+ tutorial
From: "Rusty Ballinger" <rusty@xxxxxxxxxxxxxxxxxx>
Date: Thu, 18 May 2000 15:16:40 -0700
Cc: fam@xxxxxxxxxxx
In-reply-to: Waldo Bastian <bastian@xxxxxxx> "Re: [fam] Qt/GTK+ tutorial" (May 17, 9:51pm)
References: <10005171724.ZM50294@xxxxxxxxxxxxxxxxxx> <00051721511600.00375@wantelbos>
Reply-to: rusty@xxxxxxx
Sender: owner-fam@xxxxxxxxxxx
> About the Qt example. Is it required to make the filedescriptor
> non-blocking? It isn't necassery for QSocketNotifier and I think it hurts
> for Client::readEvent() in the case when their is only a half event
> available. In theory you can end up busy-waiting in the while-loop

Well, both the Qt 1.44 and 2.0.2 QSocketNotifier class reference say in
both the text and the sample code that your socket should be non-blocking.
(I'm not sure why, as I can't imagine that Qt would ever do anything but
select on the socket.)  But you're right about that being bad for
Client::readEvent().  I didn't think of that.

It seems like the right thing to do is in the read loop in
Client::readEvent(), if the fd is non-blocking, and readEvent() is
supposed to block, do a select before subsequent reads, so that it still
blocks, but not busily.  Thanks a lot for catching that.

(I guess that's separate from the question of whether the tutorial should
say to make the socket non-blocking...  if you're sure it's not necessary,
I'll remove it.)

--Rusty

--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>