A common VFS and a Common conf-system [Part II]

Sean Middleditch elanthis at awesomeplay.com
Thu Mar 3 03:42:19 EET 2005

On Thu, 2005-03-03 at 01:06 +0000, Jamie McCracken wrote:
>Sean Middleditch wrote:

>> I can't think of any situation where you have a network protocol that
>> must be synchronous.
>Synchronous FTP?

Not really the same kind of 'synchronous' - that refers to initiating an
operation (like an upload) and waiting until it's complete.  That's
application behavior.  You can code that behavior using an asynchronous
API.  And in fact, you'd *want* to code it that way, since that way that
use can hit Cancel or watch a progress meter or so on.

Would it be better if we used the term 'event based' instead of
'asynchronous' when referring to the API?  If you *want* to code
synchronously - which is common only because it is a lot simpler - you
can build such an API on top of an event based API.  Basically you just
loop waiting for and processing events until you get the 'operation
complete' event.

>Anyway there are other elements like keeping connections alive by 
>periodic polling and live views (aka file monitoring in gnome-vfs) which 
>would also involve periodic polling/refreshing in things like FTP 
>servers. Of course you could do that without threads but it would be 
>quite messy codewise wouldn't it?

No, not at all.  Qt, glib, and countless other software packages provide
pre-written code to do just that, and in honesty it's not hard at all.

You have a group of sockets.  These are connections to servers or maybe
the connections between apps and the daemon.  All you do is just wait
for data on them and process it when it comes.  You do this using a loop
with select() or poll() or something similar.  All of those functions
take a timeout.  So if no data comes in at all within, say, a minute,
the function returns, the loop checks the time and sees how long its
been since there has been activity on connections that need keep-alive
packets, and sends out such a packet if required, then goes back to
sleeping in the poll function.

This is the way just about every single server application, daemon, or
GUI application works.  A GTK+ or Qt app does exactly that, except the
socket it waits on is the connection to the X server, and it uses the
timeouts to do things like animations or tooltip delays or whatever.

>>>>xdg mailing list
>>>>xdg at lists.freedesktop.org
>>>xdg mailing list
>>>xdg at lists.freedesktop.org
>xdg mailing list
>xdg at lists.freedesktop.org
Sean Middleditch <elanthis at awesomeplay.com>

More information about the xdg mailing list