Windows ginput function [Was: fopen doesn't return when opening a fifo!!]

[John W. Eaton]

On  2-Apr-2008, David Bateman wrote:

| Yes its only in the wait loop when ginput is active. For sleeping to
| reduce the CPU load it needs to be much longer than a time slice of the
| processor. The HZ variable in the linux kernel sets this value to
| typically 10ms. Therefore yes a 100ms sleep might reduce the CPU usage.
| However in octave, sleep(0.1) will ultimately call the libc usleep
| function, and this is implemented with a wait loop in any case. Try
| 
| while (true), usleep(0.1); end
| 
| and check the CPU load.. So doing this won't gain you anything.

Strange.  I see

  more off; while (true) sleep (0.1); printf ("."); end

printing the dots at what appears to be 0.1s intervals and watching
with top doesn't show Octave at 100% CPU (it doesn't even register in
the top 15 processes most of the time).  But with

  more off; while (true) usleep (0.1); printf ("."); end

I don't see the dots until I touch a key and Octave is at 100% CPU
usage.  So I think tehre is a bug there somewhere.

| Additionally what if the user is a fast clicker, and is faster than the
| arbitrary 0.1s delay. This will result in missed clicks.. I therefore
| thinks its better to not sleep, or use blocking reads.

I don't understand why there would be missed clicks, but maybe I'm
missing something about the implementation in gnuplot.  Wouldn't the
information about the clicks be written to the output regardless of
what Octave is doing?  Oh, I see now, we are only catching one click
for each "pause mouse any" command.  Never mind.

| I believe the attached patch should work as you'd like it to.

OK, I applied it.

Instead of checking ispc(), maybe we should just try mkfifo and see
whether it works and if not, use in-line communication?  Check the
definition of file_ops::mkfifo in liboctave/file-ops.cc.  If the
mkfifo system call is not available, mkfifo should return err == -1
and msg == "mkfifo: not supported on this system".

jwe