Return-Path: <gooseman@on.ON-Luebeck.DE>
Received: from on.ON-Luebeck.DE (on.ON-Luebeck.DE [193.29.188.2])
          by hugin.oden.se (8.8.4/8.8.4) with ESMTP
	  id NAA19052 for <dlanor@oden.se>; Wed, 8 Jan 1997 13:32:01 +0100
Received: (from majordomo@localhost)
          by on.ON-Luebeck.DE (8.8.4/8.8.4)
	  id MAA17045 for stik-outgoing; Wed, 8 Jan 1997 12:42:06 +0100
Date: Wed, 8 Jan 1997 12:42:04 +0100 (MET)
From: Peter Rottengatter <perot@pallas.amp.uni-hannover.de>
To: STiK Development <stik@ON-Luebeck.DE>
Subject: STIK: CFO #1
Message-Id: <Pine.A32.3.91.970108123421.18316A-100000@pallas.amp.uni-hannover.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: stik@ON-Luebeck.DE
Precedence: bulk
Reply-To: stik@ON-Luebeck.DE
X-UIDL: 0f1ec8a10da8899087e9ddbb252aa498




CFO : Call For Opinion ;-)

CFO #1 : The g_* issue again.

Summary of recent discussion : 

The two functions resolve() and TCP_waitstate block the calling
application. On machines without MiNT or MagiC this blocks the whole
machine due to lack of preemption. Thus the new functions g_resolve() and
g_TCP_waitstate have been invented, which internally call evnt_something
to allow for AES multitasking, to have those functions only block the
calling application even if the machine has no preemption. Although this
was a neat idea, it is somewhat unproperly implemented. Dan and I came to
the conclusion to discard these g_* functions and invent something better. 

Ronald came up with the suggestion to use the GEM $c9 function. This
function basically asks the scheduler to suspend the calling application
and give CPU time to other applications. Investigations showed that this
function is apparently available on *every* machine, from TOS 1.00 to TOS
4.04 to MiNT and MagiC all versions. It can even be called from the AUTO
folder, it just returns immediately if this is the case. It does not
require any GEM parameter arrays. It appears that this function is just
perfect for the issue here. On PC-GEM there is appl_yield doing exactly
this. Andreas Kromke calls the $c9 function _appl_yield. Binding is easy : 

void  _appl_yield (void);

_appl_yield:
      move.w  #$c9, d0       ;" Function $c9 from GEM
      trap    #2             ;" Call the GEM dispatcher
      rts

My suggestion here : 

Discard the g_* functions completely, and instead always use _appl_yield
inside the normal resolve and TCP_waitstate calls. The usage of
_appl_yield is completely transparent for the calling applications, for
the application the behaviour of the calls does not at all change. The
difference is only noticable by the user, because other applications
suddenly continue working, while with the old definition the whole machine
was blocked. 
 
So (for Dan and Martin) this function would be used whenever the resolver
or TCP has to wait. For the resolver it works this way : Contacting the
nameserver a UDP `connection' is opened, and a request send. Then the
resolver has to wait for data. Here _appl_yield is called. Afterwards the
code looks if there has been data received in the meantime, if not, call
_appl_yield again. The same scheme can be applied to the TCP_waitstate. 

Note that this is a CFO, which means it is open for discussion. The stuff
before the `My suggestion here' phrase was intented a summary of facts,
the stuff after it is to be discussed, and modified if necessary. 


Cheers  Peter

---------------------------------------------------------------------
   Peter Rottengatter             perot@pallas.amp.uni-hannover.de
---------------------------------------------------------------------

.
