To: stik@ON-Luebeck.DE
Subject: Re: [8] STIK: STIK/DIALER                                                       

On Wed, 21 Aug 1996 09:41:21 Peter Rottengatter <perot wrote: 
>
>On Wed, 21 Aug 1996, Ronald Andersson wrote:
>> 
>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 ?

Because this is the only way to have STiK applications that do not 'freeze'
during transfers like all the current ones do.


>Why can't you content yourself with the interface we have right now ?

Because I am not satisfied with the way all STiK applications are handicapped
in their ability to update windows etc.  The delay time for loading an entire
web page would not matter so much, if I could at least use the ready segement
of the page meaningfully, with scrolling etc.,  or if I could start loading a
second page into another window while studying the first page, and so on.

For IRC true multi-channel multi-window capability could be possible,
and in FTP one could continue searching directories during downloads.
(GETting more files might be possible too, but only with lowered cps.)

These things are possible on other computers, so I see no reason why they
should not be implemented on our systems too.


>I once heard the goal is to have the applications proceed working while data
>is rolling in, or even STiK is waiting for data.

Yes, and for that to work, the routines must await STiK results in event_loops,
since that is where the AES messages are delivered to applications.


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

Yes, I know that many AES routines are coded to optimize space rather than speed,
and that delivery can be delayed by the task-scheduling used in all TOS.
But we do not have to let this sorry state affect our implementation very much.

First, only those operations _requiring_ AES messaging should use it.
Wherever appropriate the traditional method of direct function calls should be
used instead, since that is one of the fastest interfaces at our disposal.

Second, event-driven does not mean that all commands or return values have to be
sent as messages.  We should also make use of semaphores to handshake transfers
between APPs and STiK (another very fast interface), and these may be polled in
timer_events where needed, or in other application loops where appropriate.


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

I'm not quite sure what you mean here...
Who dismissed what ?

In previous discussions on event driven STiK, I have maintained that we
need to preserve the traditional type of interface (possibly modernized),
and  also add an interface allowing applications to interact properly with GEM.

Whatever method can do that flexibly and reliably, will have my support.


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

Ah, here we reach agreement.  This is precisely the sort of 'Semaphore' I speak
of above (hadn't gotten this far when I wrote it), except that I think that both
the flag and the buffer should be provided by the application, because it is not
acceptable that one APP lock up STiK's internal resources any more.

In fact a new structure could be declared, encompassing this flag, the buffer,
and any other stuff we find necessary. Such might include latest poll time to
allow STiK to judge if a client has 'locked up' and then set a flag telling the
client (if he ever wakes up) that he must restart his operation.

For multi-client use STiK can then have a:

'struct client_blk *client_list[ MAX_CLIENTS ];'

or something similar to keep track of all currently active clients.


>If an application knows it can't poll for several seconds it can provide a 
>reasonably large buffer.

Yes, and in the structure I mentioned there could be a 'max delay' entry,
so that STiK is aware of how long the application can be absent before it
must be considered 'locked up' or 'crashed' (for we must handle such somehow).


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

The necessity is surely obvious to anyone who has seen how poorly CAB, or most
other clients respond to GEM operations during transfers, though this is more
obvious under multitasking systems than under singletasking TOS.

I fully sympathize with your worry concerning speed, but I happen to believe
that we are currently _losing_ speed by having the APPs locked up while waiting
for network data limited by modem speeds.  Such waiting is improductive.

Whatever update-messages AES has sent while the APP was locked will be waiting
in the message queue and have to be serviced later anyway.
And data will not trickle in at a slower speed from the modem, just because we
happen to do something else than passively waiting for it.

The main speed thiefs you seem to worry about are the AES messages, and here I
quite agree with you.  The actual transfers should _not_ be handshaked by such
messages, which may however be very useful for other (not time-critical) things.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
