Pausing a program - poll/sleep/threads?

[Jeff Shannon]

Simon John wrote:

> As far as querying the server every few seconds, it does make sense
> (you don't miss events) and is the recommended way of doing things with
> InetCtrl, but I'd prefer to save the bandwidth/server load than have
> realtime status updates.

The amount of bandwidth and server load that will be used by a 
once-a-second query is probably pretty trivial (unless you're 
expecting this to run over internet or dialup networks -- and even 
then, it's probably not going to be worth worrying about).  Even on an 
old 10Mbit ethernet connection, a couple of extra packets every second 
will not make a notable difference.  This (IMO) is premature 
optimization.  :)

> The status also updates whenever you send a command (like play/pause).

But does the server push events to the client?  If there's a 
filesystem error while a track is playing, how does your client know 
about it?  In addition, what happens if XMMS segfaults, or the server 
machine loses power?

> I'm really stuck on how to implement this now....

One of the big questions here is whether your client will have 
exclusive access to the XMMS server.  That is, will it be possible for 
more than one such client to connect to the same XMMS, and/or for XMMS 
to have direct interaction on its host machine?

If you have exclusive access, then changes in the status of XMMS will 
only happen when 1) you change it yourself, or 2) there is an error. 
In this case, you can check status much less often.  (However, you'll 
still want to deal with the error conditions, which probably means 
checking at a much shorter interval than expected track length.) If, 
on the other hand, there may be more than one client/user interacting 
with XMMS, then you also have to deal with the possibility of your 
server changing status without your client taking direct action.

I really think that you *do* want to do fairly frequent status checks 
with your server.  The cost is small, and the gains in responsiveness 
and robustness are potentially very significant.

Jeff Shannon