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

[David Bateman]

John W. Eaton wrote:
> On  2-Apr-2008, David Bateman wrote:
>
> | What about something like the attached? Its not a changeset yet as I
> | haven't written the changelog and I'm not sure its the right thing to
> | do. Will there be any nasty effects of using popen2 to open a pipe to
> | the gnuplot process for example? Comments?
>
> I can't think of any at the moment.  I've avoided doing this in the
> past because I didn't think parsing the output from gnuplot would be
> reliable.  Will the output change from version to version?
>
> Should the output that doesn't match what we are looking for be
> displayed or discarded?  Error messages from gnuplot go to stderr,
> correct?  If so, then at least those won't be lost.
>   
It is the __gnuplot_ginput__.m function that sends the command to print
to  gnuplot, so we are in full control of the output. To try and address
some of these issues, I added a tag in front of the expected output (ie
"OCTAVE:") and so we can reject the rest. I see the output stream from
gnuplot opened with popen2 to be blocking reads just around the read
statement to prevent the need to a while loop around the read, though if
you feel the while loop is better to allow ctrl-c to work then that's
easy to implement as well. I should probably also have a while loop
looking for the expected "OCTAVE:" tag as well, to prevent rubbish that
might be printed by gnuplot affecting the use of ginput.
> If it works, then why not use popen2 unconditionally?
>   
The read of the fifo blocks, but doesn't use resources and is
interruptible with ctrl-c, whereas a blocking read on the pipe doesn't
seem to be without quitting Octave. Also as the fifo is only for the
mouse data, there can be no confusing with any other output from
gnuplot. I think the mkfifo method is more secure for this reason.

In all cases the pipe to gnuplot is opened with popen2 in my proposed patch.

D.




> jwe
>
>   


-- 
David Bateman                                David.Bateman at motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary