Re: [MiNT] patch:MiNT:single-task

[Alan Hourihane <alanh@fairlite.co.uk>]

On Wed, 2010-06-02 at 15:16 +0000, Helmut Karlowski wrote:
> Alan Hourihane wrote:
> 
> > Could PD have redirected output to file descriptor -1 ?
> 
> Is there a way to test this? If it would be redirected then the close
> should be performed.

A test app could be made - yes.

> > By not closing are we risking losing some data here.
> 
> Yes, this could possibly occur.

Ouch, I don't think that's acceptable.

> > Can you give some help on what F/M_DONT_STOP imply ?
> 
> From my changelog:
> 
> ---
> To control this currently there has to be the bit 16 (0x10000) set in
> p_flags of the relevant binary.
> 
> Any client that has bit 17 (0x20000) set, is not stopped except when the
> single-task-app has this bit also set, i.e. when it has 0x3xxxx.
> ---

Are you saying that sending a signal such as "SIGKILL" to the
application wouldn't stop it ?

> Ths F_defines are used in p_flags in the basepage and configurable by the
> user. Because XaAES cannot access the basepage of other processes, they
> are translated to the new proc.modeflags (The M_-defines). The use of
> modeflags also eases the code a bit (not 4 -> but 1).
> 
> > What happens with the existing keyboard timeout routines that you need
> > to bypass them ?
> 
> I'm not sure if I understand what you mean. The pending timeouts when
> ST-mode is entered? I don't think there are any and if so, it's not a
> desaster to lose 1 keypress (a lost release cannot do anything because
> there is no keyrepeat in ST-mode).
> 
> The reason to bypass the timeout is that PD disables the timer-interrupt
> (I think) and there would only be one keypress possible. The same
> happens when you boot with GEM=ROM on original hardware (don't know why
> it happens there). I was thinking to extend this for the ROM-desktop to
> have keyboard there too.

Are you saying you get no key events when using the current code ?

I think I'll go and grab PD to see what gives.

Alan.