Return-Path: gooseman@ON-Luebeck.DE
Received: from nikson.dataphone.se (root@nikson.dataphone.se [194.23.92.5]) by hugin.oden.se (8.7.5/8.7.3) with ESMTP id JAA22806 for <dlanor@oden.se>; Wed, 21 Aug 1996 09:45:29 +0200
Received: from brewhq.swb.de (brewhq.swb.de [193.175.30.3]) by nikson.dataphone.se (8.7.5/8.6.12) with SMTP id JAA16586 for <Ronald@dataphone.se>; Wed, 21 Aug 1996 09:47:44 +0200
Received: from on.ON-Luebeck.DE by brewhq.swb.de  with smtp
	(Linux Smail3.1.29.0 #5) id m0ut7wh-0003Aha; Wed, 21 Aug 96 09:43 MET DST
Received: (from majordomo@localhost) by on.ON-Luebeck.DE (8.6.12/8.6.12) id JAA24239 for stik-outgoing; Wed, 21 Aug 1996 09:41:47 +0200
Date: Wed, 21 Aug 1996 09:41:21 +0200 (MEST)
From: Peter Rottengatter <perot@pallas.amp.uni-hannover.de>
To: stik@ON-Luebeck.DE
Subject: Re: [7] STIK: STIK/DIALER
In-Reply-To: <199608202342.BAA11560@freke.oden.se>
Message-Id: <Pine.A32.3.91.960821092121.23689D-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
Status:   


On Wed, 21 Aug 1996, Ronald Andersson wrote:

> As for the future STiK GEM additions, on second thought I believe that they may
> be best handled by having the (then mandatory) Dialer ACC call a new STiK function
> that will transfer control to a main GEM event loop located inside STIKTSR.
> 
> One argument to this function should be a pointer to a subroutine that handles all
> things the Dialer ACC wants for itself in the event loop.  This leaves it up to
> STiK to decide when it has time to run through the Dialer stuff, so that less
> time is wasted on that during intensive downloading etc.
> 
> It also allows Dan to develop all kinds of GEM additions inside STIKTSR, without
> bothering to implement new interfaces for how the dialer can reach them, since
> STIKTSR itself is in control.
> 
> The new STiK will need a highly efficient kernel containing both interrupt-driven
> and GEM_event-driven routines, and these can interact most efficiently if they
> directly share certain global data, which requires that they be linked directly.
> 
> There may be (are) other methods to achieve this, but whichever is chosen I think
> it's important that STiK kernel routines somehow control the Dialer, rather than
> the other way around, since the other ways would cost more CPU time.


This sounds feasible. But there is still a point I do not understand. Why 
are you so keen to have a GEM event driven interface ? Why can't you 
content yourself with the interface we have right now ? I once heard the 
goal is to have the applications proceed working while data is rolling in, 
or even STiK is waiting for data. Don't you realise that this might become 
a real bottleneck on older machines, as GEM messages take a serious amount 
of time until they get delivered, particularly on machines with the 
original, inefficient TOS versions.

If this is really the only goal, then I'd like to suggest a different way 
of doing it. If it happens that you don't like it, dismiss it, but note 
that this is exactly what happened to me with the event driven STiK.

Why not having applications polling a flag inside STiK to see if data is 
there. This is similar to what happens now. The drawback is that some 
applications might not as regularly poll the flag and read the port. 
Couldn't this resolved by letting the application provide the buffer ? If 
an application knows it can't poll for several seconds it can provide a 
reasonably large buffer.

I guess you have more in mind with the event driven STiK. Please convince 
me of the neccessity of this beast.


Cheers  Peter

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

.
