[Top][All Lists]

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

RE: [Help-smalltalk] Re: Compiling gst with mingw32

From: Akeroyd, FA (Freddie)
Subject: RE: [Help-smalltalk] Re: Compiling gst with mingw32
Date: Mon, 1 Oct 2007 19:37:54 +0100


I think the problem is that the change of window generates a focus
change console event; this counts as "input available" and so wakes up
the process, but as there are actually no characters to read win_recv()
lib-src/socketx.c returns 0 which is converted into a POLLHUP by 

A nasty workaround is to edit lib-src/socketx.c and change the final
line of win_recv() to

return (nread == 0 ? 1 : nread);

This will cause the calling read() operation to block for input, which
will be OK so long as the process is not waiting on multiple input

I'll have a think about a better fix



-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf
Of Cesar Rabak
Sent: 30 September 2007 06:10
To: address@hidden
Subject: [Help-smalltalk] Re: Compiling gst with mingw32

2007/9/29, Stephen Compall <address@hidden>:
> On Sat, 2007-09-29 at 16:23 -0300, Cesar Rabak wrote:
> > However, after I interact with it a little if I put the focus in any
> > other Windows application, gst returns to the operating system or
> > saying in other terms: the commad prompt turns back to CMD (e.g.
> > C:\>).
> >
> > Do you have seen anything similar to this? I'm not sure nor from
> > start to debug this!
> Yes, Windows halts (but does not kill) all processes run under a
> prompt when they are out of focus.  Oddly, this doesn't apply to
> which seems to handle it correctly somehow.  The place to start would
> to figure out what Windows does to stop cmd processes in this case and
> fix the VM to ignore the signal (or something) on Windows.  But first
> would check the Cygwin version to make sure it doesn't happen there on
> your system.

I'll need to wait if some other person reading this list has built a
Cygwin version and has the same behaviour.

> I learned about that the hard way when trying to run a long
> process in a background cmd window. :)

I'm starting to understand why a lot of programs ported to Windows
have their own "shell" while in Linux they just have a toplevel in
command line...

gst seems to be usable for running scripts and even works integrated
with Emacs in Windows.


Cesar Rabak

help-smalltalk mailing list

reply via email to

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