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


On Mon, 26 Aug 96 20:36:34 G Guy Harrison <test@swampd wrote: 
>
>  Ronald Andersson <dlanor@oden.se> wrote:-
>
Well Guy, it appears we agree on quite a bit about your message system,
so I'll snip out a lot of stuff below as 'finished business'.

----- snip ----- re: general purposes etc

>However, it _could_ be used. It allows us the possibilty to implement 
>a message interface to STiK at a later date and to do it very much 
>faster than appl_write() ever could. I'm not suggesting that a 1:1 
>mapping of the current cookie interface ever be done - just it gives 
>us the possibility to do so.

Ok, an added capability in itself does no harm, although I doubt if all
things possible with direct functions will work as well with messages.
Some functions must return a direct response, which appl_write can not.


>>>If the buffer is a reasonble size, it could be used for data transfers 
>>>between clients if the need arises.
>>
>>I do not agree, it would be far easier to stick to the standard AES 
>>message size, and let clients use this block to tell each other where 
>>data buffers really are. The main message buffer becomes a global STiK 
>>resource, and should not be so easily abused by any client, perhaps 
>>preventing others from efficient use.
>
>You have a valid point and this needs discussing. At the moment I 
>ought to stress that I am proposing a buffer which can hold data - 
>nothing more, and exploring the possibilities from this level. One of 
>these possibilities (and the most important imo) is that it could 
>emulate AES messages. The buffer itself would be completely unaware of 
>this, consisting of little more than code to insert, find, read or 
>remove data within it.

I do see your point, but using a standard message size would mean that all
block moves, index scaling, and other stuff would relate to compile-time
constants, rather than to content defined block limits at run-time.
This makes a major difference for the execution speed.


>This means that memory protection would only need be disabled whilst 
>the source app was having the filename transferred to the buffer. It 
>is a minor point really.

I never use memory protection mode myself, but I agree.


----- snip -----

>>>The rest are accessible through the cookie ...
>>>
>>>int    put_mbuf(int apid, void *app_buff, int msg_size)
>>>
>>>writes msg_size bytes from app_buff into the buffer. Returns the 
>>>number of bytes written or a negative error.
>>
>>Are you sure we want to allow extended messages in this buffer...?
>>Ok, so this format is defined for the AES too, but when is it used ?
>
>I've never seen it used. But from further above you will know why.

Yes, but I have my doubts about how this will affect speed.


----- snip -----

>>In fact we gain a lot of speed by declaring the entire buffer as an 
>>array of 16-bit words, especially if we stick to the standard 8-word 
>>message format.
>
>If we stipulate the minimum message size must be 16 bytes we lose 
>nothing as all msg[] buffers must be at least this length. I suggest 
>an array of longs as they map onto this. Could even state that 
>transfers of longer length will have to be long aligned - no big deal 
>really.

----- snip -----

>>>int    get_sbuf(int ibuf)
>>>
>>>Return size of message ibuf or negative error.
>>
>>Why not follow the normal AES usage instead, and let 'is_msg' get all 
>>8 words of the standard message, since they will normally be needed 
>>anyway.
>
>If an app was being selective then this would require a transfer for 
>each message the app looks at. Having it return msg[0] automatically 
>in most cases will allow it to disreguard the message without have to 
>check any more of it.

Yes, but the transfer would only be 8 words, and that can be done by 2
opcodes in a total of 20 accesses (compared to 1 op in 3 accesses for 1 word).
This also allows selectivity applying later words of the message, which could 
be important, since old plans only included one 'IP' message reserved for STiK.

All the index and pointer calculations needed for a transfer will have to be made
here anyhow, and if data is then to be fetched separately it'll have to be redone.
That's why I think doing the transfer here will actually save us time.

For extended messages some other method could be used, which is what AES does.
As you propose it, all messages require the extra 'read' call which AES only
uses for messages in extended format (ie: almost never).


----- snip -----

>>>with kill_mbuf() else the next app that gets that apid will get the 
>>>previous app's unread messages. I guess it would need to be done once 
>>>the app has closed its last socket but this does not cover crashes. 
>>>This one needs your input Dan!
>>
>>Maybe, but I will have my say too.
>>
>>This can easily be solved, if an array is maintained holding a 
>>structure for each application having a message waiting in the buffer. 
>> This structure would contain the applications identifier, the number 
>>of messages waiting, and the time when the application last polled for 
>>messages.
>>
>>A variable also keeps track of the time we last made what I call a 
>>'safety check' of the structure array, so this is repeated at regular 
>>intervals.  That variable should be checked against current time at 
>>start of each 'put_mbuf' and those 'is_msg' calls with flag==0, to 
>>clear out messages to 'dead' applications, by checking the array for 
>>applications not polling recently.
>
>This is indeed possible but how would we specify a Tos program's 
>application identifier?

Several ways are possible, that could either complement or replace the
GEM application id.  I suggest complementing by using negative id's for
non-GEM programs, assigned/released by an init/exit function pair.
This is also the model closest to what AES itself uses.

Assigned TOS_type ids should of course also be released automatically,
when any application fails to poll properly, and its messages are cleaned
out of the buffer.


----- snip -----

>Sorry! Unlike evnt_mesag(), the message stays in the buffer until we 
>clear it out with clr_msg(). If we did not do so, we would get the 
>same message over and over again. I think this is useful. An app could 
>be buried down in some intensive processing in the following *very* 
>loose example <G> ...

>calc_answer_to_universe()
>{
> for (/* huge great loop taking ages */)
> {	if (is_msg(apid,0,&msg0) && msg0 == VERY_IMPORTANT_MSG)	return;
>}}

>deep_thought()
>{ for (;;)
>    {   Evnt_Multi(/* our modified code */);
>        if (MU_MESAG)
>        {   switch (msg[0])
>            {   VERY_IMPORTANT_MSG:   blah();
>}   }   }   }

>The only point I'm trying to make with the above, is that the 
>intensive processing can stop leaving the message intact, we get to 
>our Evnt_Multi(), which reads and clears the message.

Ok, that is clear, and I do agree.  Prioritizing is very important,
and the lack of such is a problem in the AES message implementation.

BTW, if the 'Heart of Gold' had had prioritization, Arthur's famous
'Tea question' would not have had half as exciting consequences.

----- snip -----

>>>Possible Addition:
>>>
>>>It might be worth considering implementing a timer message. After a 
>>>specific time the sender gets the message back.
>>
>>That requires some highly regular interrupt for STiK itself, such as 
>>the 200Hz system interrupt, but that must be highly speed-optimized 
>>and may even be needed for entirely different purposes in a new 
>>improved STiK version.
>
>I can't make my mind up about it. evnt_timer() will serve in most 
>cases. I can't think of any use for it except by Tos programs, and if 
>they needed a decent delay then they ought to make their own 
>provisions.

Precisely.  We are, after all, not implementing a new AES here,
but only adding a more STiK-oriented message system.


>>Ok, I think the idea is worth looking into as a complement to the 
>>interface. (Provided that is, that my assumptions of what you really 
>>mean are correct.)
>
>Your assumptions are, except in one area.
>
>You are looking at it as a message replacement. Nothing wrong in that 
>because I see that as its main use also. :-)
>
>I am looking at it as a general purpose buffer which can support 
>messages. Anything I can add which does not adversely affect the 
>message replacement, I will add!

Given that condition I have no particular objections.
My only worry is that trying to keep things 'too' general may prevent
optimizations that could make a major difference in terms of speed.

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