From: wusel@hamburg (Kai 'wusel' Siering)
Date: Thu, 09 Apr 1992 23:44:11 GMT
Organization: Villa Straylight, Hamburg, FRG
Newsgroups: de.comp.sys.amiga.misc
Reply-To: wusel@hactar.hanse.de (Kai 'wusel' Siering)
Subject: Re: Multi-User am Amiga
X-Newsreader: Ann 0.8l
Content-Type: text/plain; charset=ISO-8859-1
X-Copyright:  Jegliche  Verwertung - insbesondere unter Angabe des Autors oder
              der   Organisation   -   ausserhalb   des  USENETs  bedingt  den
              komplettem  Abdruck  des  Headers  und ist nur mit schriftlicher
              Genehmigung  des  Autors  gestattet.  Um  ein Belegexemplar wird
              gebeten.

In article <Marcus_Kuba.071g@ibase.stgt.sub.org>,
	Marcus_Kuba@ibase.stgt.sub.org (Marcus Kuba) writes:

% wusel@hamburg (Kai 'wusel' Siering) wrote:
%
% % >Wenn man davon absieht, dass das ungewollte Oeffnen eines Fensters
% % >den Tod bedeutet, wenn der Operator nicht an der Video-HW sitzt. (Was
% % >mir kuerzlich in einer Mailbox passiert ist. Daraushin war die Box
% % >erstmal fuer ein paar Stunden dicht.)
%
%  KS> Was aber  auf  die `Intelligenz' der Box-Soft schlieszen laszt -
%  KS> einen Groszteil   der  Requester  kann  man  doch  locker  auf
%  KS> per-Prozess-Basis abschalten  (der  hier  benutzte ls macht sowas zum
%
% Das hat damit _ueberhaupt_ nichts zu tun, natuerlich werden alle
% System-Requester abgeschaltet (ausser vielleicht "Disk Full" oder "XYZ...
% Program failed"...), aber es geht hier nicht um System-Requester, sondern
% normale Fenster, die von irgendwelchen Programmen geoeffnet werden.

Ja, ok, schrieb ich ja auch schon, DME, CED etc. sind toedlich.

% Stell Dir mal vor Du bist CoSysOp einer Mailbox mit DOS-Zugriff und Du
% loggst Dich von zuhause aus ein. Irgendjemand hat ein Archiv "VollGeil.zom"
% hochgeladen und Du moechtest gerne wissen, was da drin (d.h. auf der Disk
% drauf) ist. Nichts leichter als das... geh'n wir mal in die Shell und
% entpacken das ganze auf die dafuer eingerichtete FMS-"Diskette". Wenn Du
% jetzt durch einen dummen Zufall (und die kommen immer in solchen Momenten)

Wem sagts Du das? =:-<

% beim Aufruf von ZOOM die Parameter weglaesst, dann laeuft das Teil eben
% nicht mehr in der Shell, sondern macht auf dem Mailbox-Rechner 2 Fenster
% auf und Du kannst Dich auf den Weg machen...

     Ok, aber  hier  meine  ich,  waere bei einem Timeout eine Entkoppelung
von  seriellem  Port  und  gestartetem  Programm sinnvoll. Es ist doch wohl
sicher  besser,  die Programme laufen zu lassen (in Ermangelung eines `kill
-9'-Aequivalents)  und  ein  wenig  Speicher  zu  verlieren,  als  die  Box
geplattet  zu  haben  -  meine ich jedenfalls. (Disclaimer: In wie weit das
aufbrechen   einer  FIFO  und  neu  zusammenhaengen  (z.  B.  <nil:  >nil:)
realisierbar ist, habe ich nicht naeher untersucht.)

%  KS> pr_Console=-1l oder so, wenn ich mich nicht  irre.   Und  bei  einem
%  KS> Timeout gehoert der Port gefaelligst wieder freigegeben  (was  ich
% mit
%
% Bei entsprechender Software kein Problem.... wenn z.B. der oben erwaehnte
% ZOOM beim Empfang eines BREAK-Signals seine Fenster wieder schliessen
% wuerde und sich verabschiedet, dann muesste nur der handler, der fuer die
% serielle Schnittstelle zustaendig ist, beim Verlust des Carriers
% ebensolches Signal an den gerade laufenden Prozess (in obigem Beispiel
% ZOOM) schicken und die Sache waere gegessen (so versucht es der handler bei
% meiner Software). Aber da das die wenigsten Programme tun (ausser denen,

     Hmmm ...  Nuetzt  Dir  z. B. bei CED aber nicht die Bohne, bestenfalls
brichst Du auf die Shell - oder?

% die eh nur in ner Shell laufen...), und das BS derzeit keine Moeglichkeit
% bietet, einen solchen Prozess sauber rauszuschmeissen, muessen wir beim
% Amiga eben SEHR vorsichtig mit sowas sein.

     Naja, man  _koennte_  das Prg. ja `freezen' (Taskstatus auf unbenutzen
Wert   setzten)   und  dann  RemTask()  aufrufen  ...  Bringt  aber  auszer
Absturzgefahr  und  Speicherplatzverlust  wohl nichts =:-< Daher meine ich:
einfach laufenlassen, aber wenigstens von der seriellen abkoppeln.

%  KS> Nutzt Dir  ggf.  auch nix - hactar z. B. schmollt seit Einbau der 2630
%  KS> nach  jedem  Absturz,  vor  den Alert hat  irgendwer/-was 'nen
%  KS> `Affengriff' gesetzt   =:-<   Die   einzige   funktionierende Loesung
%
% dieser irgendwer/-was nennt sich (Set)CPU FASTROM... wenn man das BS nicht
% ins 32-Bit-RAM kopiert funktioniert alles tadellos...

     Oerks! Yupp  stimmt  -  peinsam;  ich ziehe die implizierten Vorwuerfe
zurueck.   Aber `KillZKick' macht immer einen schoenen sauberen (jedenfalls
klappt  er  =:->) Reset, auch bei FASTROM ... Gibt's einen Patch, um Alerts
& FASTROM unter einen Hut zu bekommen?

%  KS> ist  imho ein Hardware-Watchdog; 5 Minuten kein Signal? *RESET*
%
% 5 Minuten ist eindeutig zu wenig... was passier, wenn mal eine Stunde
% keiner anruft ??? Dann kommt auch kein Signal und der Rechner wird alle 5
% Minuten neu hochgefahren ??? Oder laeuft dann ein Programm, das alle 4
% Minuten ein Signal schickt ???

     Letzteres. Aber  sagen  wir lieber 30 Minuten, wer weisz, wie lange es
dauert, bis das Programm bei validierender Platte gestartet wird ...

MfG,
			kai

--  _
 _ //    Kai 'wusel' Siering, Villa Straylight, Hamburg, West Germany
 \X/: <wusel@hactar.hanse.de> Exile: <wusel@lime.in-berlin.de> iso-8859-1: 

"Welches ist ihr Lieblingsbuch?" - "Krieg und Frieden; die erste Haelfte davon"
                                                                -- Sledge Hammer
Newsgroups: de.comp.sys.amiga.misc