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 21:05:25 -0700
Cc: fam@xxxxxxxxxxx
In-reply-to: "Rusty Ballinger" <rusty> "Re: [fam] Qt/GTK+ tutorial" (May 18, 3:16pm)
References: <10005171724.ZM50294@xxxxxxxxxxxxxxxxxx> <00051721511600.00375@wantelbos> <10005181516.ZM2975@xxxxxxxxxxxxxxxxxx>
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
...
> 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.

Actually, after looking at it, I think it's OK the way it is.  FAMNextEvent
won't busy-wait on a non-blocking socket, because when the read in
Client::readEvent() fails (with errno == EAGAIN/EWOULDBLOCK), readEvent
bails, and FAMNextEvent will return an error (leaving errno == EAGAIN), which
seems reasonable.  (If the caller doesn't want the error, they shouldn't call
FAMNextEvent on a non-blocking socket until FAMPending says an event is
ready.)  Does that make sense?  I'll fix the man page to encourage the use of
FAMPending.

--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>