From mint-bounce@lists.fishpool.fi  Wed Jun  2 11:19:32 2010
Message-ID: <892706.395683007-sendEmail@descaro>
From: "Helmut Karlowski" <helmut.karlowski@ish.de>
To: "Alan Hourihane" <mint@lists.fishpool.fi>
Cc: "helmut.karlowski@ish.de" <helmut.karlowski@ish.de>
Subject: Re: [MiNT] patch:MiNT:single-task
Date: Wed, 2 Jun 2010 15:16:50 +0000
X-Mailer: sendEmail-1.55
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----MIME delimiter for sendEmail-993440.290288166"
X-Antivirus: avast! (VPS 100602-0, 02.06.2010), Outbound message
X-Antivirus-Status: Clean
X-ecartis-version: Ecartis v1.0.0
Sender: mint-bounce@lists.fishpool.fi
Errors-to: mint-bounce@lists.fishpool.fi
X-original-sender: helmut.karlowski@ish.de
Precedence: bulk
List-help: <mailto:ecartis@lists.fishpool.fi?Subject=help>
List-unsubscribe: <mailto:mint-request@lists.fishpool.fi?Subject=unsubscribe>
List-Id: <mint.lists.fishpool.fi>
X-List-ID: <mint.lists.fishpool.fi>
List-subscribe: <mailto:mint-request@lists.fishpool.fi?Subject=subscribe>
List-owner: <mailto:tjhukkan@fishpool.fi>
List-post: <mailto:mint@lists.fishpool.fi>

This is a multi-part message in MIME format. To properly display this message you need a MIME-Version 1.0 compliant Email program.

------MIME delimiter for sendEmail-993440.290288166
Content-Type: text/plain;
  charset="iso-8859-1"
  Content-Transfer-Encoding: quoted-printable

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.

> By not closing are we risking losing some data here.

Yes, this could possibly occur.

> 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.
---


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.

-Helmut



------MIME delimiter for sendEmail-993440.290288166--


