Re: "pause mouse close" almost works, but not completely

I just hit another bug in the same area; a more serious one this time.

When I run gnuplot normally with 'pause mouse close', it blocks
somewhere, and doesn't waste cycles while we're waiting. In my usage,
however, I rarely run gnuplot directly. I almost always use either
feedgnuplot (a shell frontend) or gnuplotlib (a plotting interface for
numpy in python). At least in the latter case, the 'pause mouse close'
works, but gnuplot spins instead of blocking, which wastes CPU
resources.

I'm attaching a tiny program in python that shows the issue. You should
change the GNUPLOT_SRC_DIR definition in that program to point to your
source tree. This test program

- spawns gnuplot (as a child of the python)
- asks it to plot something
- "pause mouse close"
- "print xxx"
- reads gnuplot output until it sees "xxx". This is the most reliable
  way I've found to let programs talk to gnuplot. If you know of a
  better synchronization method, please tell me

When I run this python program I see gnuplot repeatedly call usleep(10)
in X11_waitforinput() in x11.trm. I haven't looked enough at this code
path to understand what it's trying to accomplish. It feels like we
should never be doing this: all waiting should happen in the select() or
something like it. I also don't understand why I'm hitting this code
path in python, but not if I run gnuplot interactively ("gnuplot" and
then type in the commands) and not if I run it as a script (put the
"plot" and "pause mouse close" into tst.gp, and "gnuplot tst.gp").

Ideas?

Thanks