octave-maintainers
[Top][All Lists]
Advanced

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

Win 98 support patch


From: John W. Eaton
Subject: Win 98 support patch
Date: Tue, 29 Jul 2003 12:30:32 -0500

On 25-Jul-2003, Paul Kienzle <address@hidden> wrote:

| The attached patch removes some major inconveniences when running
| under Windows 9x.  Simple commands like ls or help would freeze
| the computer for 7 sec then give a series of dire warnings about
| each loaded oct-file.
| 
| As far as I can tell, the patch doesn't remove any useful
| functionality.

What about not being able to get the actual PID of the subprocess?
Perhaps we never use that anywhere?

| The correct status is still returned function calls.  Interrupts still
| break the piped application rather than killing octave.  Killing the
| pager still leaves the keyboard echo turned off in the console, only to
| be fixed by system('reset').  Octave still responds appropriately if it
| detects that gnuplot has been killed (which BTW it may not since pgnuplot
| doesn't die when the gnuplot console is closed).  This is despite the
| fact that SIGCHLD isn't being handled correctly (SIGCHLD should use
| default signal handling rather than doing it's own waits if popen is
| in effect according to the docs --- this may not be the case for
| octave_iprocstream under unix), and despite that fact that the
| buffered child cleanup function is not being called (though I didn't
| look in detail at what child cleanup is needed for pager/gnuplot).

OK.  I'm not sure what is correct for handling SIGCHLD.

| I haven't removed the fork in system('cmd','async').  In practice,
| users can say system('cmd &') instead, so it isn't too much of an
| issue.

But can they still get the PID of the subprocess?  OTOH, I think that
you actually get the PID of the shell process anyway, so I'm not sure
how useful that is.

In any case, I've installed your changes.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]