[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Beta Version - Please help



amc45@cornell.edu wrote:

> as i see it, there are two ways to do this.
> the first is to use the gettimeofday function, and set a variable, say
> oldtime, to it.  then just loop, or sleep until the gettimeofday function
> returns the first oldtime+delaytime...but personally (and i'm not sure
> how true this is) i've found that the gettimeofday function is really slow.

Looping for a delay is a *very* bad thing to do in Unix BTW!!! And it
makes you look so "DOS", people won't want to talk to you after! ;-)

The reason is that looping in this manner makes your process seems very
busy, and will give it as much CPU it needs, for is actually *WAITING*.
I don't know for you, but I prefer my XMMS not to skip instead. :-)

Most operations are "blocking" in Unix, that is, they won't return until
they are finished. In many cases (like printf("hello\n");), you don't
notice, because it takes so little time to finish, but for longer things
(like fwrite(buf, 128, 1024, file);), the kernel knows you are waiting
for the disk to finish writing (for example) and marks you as "waiting
for disk" and will let other processes that don't need the disk run on
the CPU instead.

This leads to the kind of efficiency you see in Linux. If you start
doing things like for(i = 0; i < 100000; i++);, you're being rude to
other processes and slowing the whole thing down for no reason (for
example, another process that is writing to disk might not run even if
the hard disk is now ready).

Some things, like a 3D renderer, are okay not to call any blocking
operations for a long time, because they actually *use* the CPU time
they are given. Quake uses a lot of CPU, but that's fine.

But an application that does *nothing* eating up 92% of my CPU will get
me very mad.

> um, excuse my ignorence, but i don't rightly know if you're doing this
> under x or console.  if you're doing it under x, then the main idle loop
> can look for keyboard hits at any time.  if you're doing it under
> console, i believe there is a way to make io non-blocking via fcntl,
> using the F_SETFL operation and setting the O_NONBLOCK bit, or using
> ioctl with the FIONBIO operation (?????)

No need to be non blocking. You use poll or select instead, which is
like "peeking" at the input without blocking for long (just like a
printf if you set timeout to zero).

> > And the last thing is the Background music. I just forked and updated
> > mikmod in the background, but it is still playing, when I stop the
> > program with CTRL+C.
> you just have to let your different forked processes talk to each other
> either via a pipe, shared memory, or the like, and then if one gets an
> exit signal then it will the tell the other accordingly.

Signals are a form of IPC, and for the matter at hand (such a simple
message as "stop!"), they are quite sufficient. Keep the pid handy and
kill(pid, SIGINT) at the appropriate time. (kill() is a nastier name
than it actually is, as most signals actually don't even stop or kill
the process! (SIGCHLD, SIGCONT or SIGWINCH are good examples)

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi