To: perot@pallas.amp.uni-hannover.de
Subject: Re: [2] Ownership problems again, oh no ...                                         


On Tue, 7 Jan 1997 14:55:19  Peter Rottengatter <perot wrote: 
>
>On Tue, 7 Jan 1997, Ronald Andersson wrote:

----- snip ----- re: STiK_exec function (call function with p_run = STiK)

>> Having such a function in the interface easily can easily lead to abuse,
>
>I'd do it for the STX only, so only *.STX modules would be allowed to 
>use it. Programmers who work on clients won't even have the information 
>to use it. Don't you think that's safe enough ?

That's different of course, I thought you meant the client API.


>> and internal functions should not use it anyway, since a macro is faster.
>
>Speed is not an issue here, as it is *very* rarely called. Mind you, 
>right now we only need it for opening and closing a port, which is only 
>caused by ConfSTiK, the CPX, or the Dialer.

Right now yes, but what about later...?


----- snip ----- re: STiK_base_p pointer (to STiKs basepage)

>Yes, but this is precisely the reason why I thought the overhead to be 
>neclectable. The call will always include two traps, which are Supexec to 
>do it in Super mode, and the GEMDOS call to be done in STiK's context. 
>Traps are so slow, you can do heaps of other instructions meanwhile, and 

That is unfortunately true for GEMDOS more than for BIOS and XBIOS.  It is
not the trap code itself which is slow, but the GEMDOS function interface.
This is extremely overcomplicated and inefficient, but can't be avoided.


>after all, the function I'd provide would only need two JSR/RTS more than 
>the C code you wrote above. The function I suggested would only do a 
>single Supexec, which calls a routine that consists of the few lines you 
>wrote above, with the only exception of the Fopen being replaced by a 
>call to the user function. Don't you think the overhead is almost not 
>there ?

Actually there is more than just JSR/RTS, since the function pointer must also
be pushed before, read during, and removed after the STiK_exec call.  Even so,
You are right in that the time wasted may be a low percentage compared to the
extensive waste in the GEMDOS function interface.


----- snip ----- re: more on speed of STiK_base_p vs STiK_exec
>> 
>> The most flexible solution is of course to include both in the API.
>
>Maybe I should do this. However, the most convincing reason to not 
>provide the basepage pointer is that if the method becomes illegal, 
>because for instance Andreas indeed did change the p_run behaviour, 
>we'd only need to change STiK, not every client. This makes me 
>hesitate to supply the pointer too. Did you take this into account ?

Actually this weakness applies to both methods, but in various ways.
If Andreas changes the 'p_run' behaviour it will probably be to create
different means of controlling ownership of various things.  This may
mean that no single method of choosing ownership for different types
of things (eg: RAM, files, devices, pipes, forks) will exist anymore.

In such case no single STiK_exec function can solve the problem.
It will then be necessary to extend the API again, regardless of
what method we choose right now.

Summing up:

I guess I exaggerated the influence of STiK_exec on overhead costs a bit,
so actually either method can be used with no large difference in speed.
They are functionally identical, but STiK_exec does save some code in all
calling modules by providing a callable function, at a slight speed cost.
Either choice is ok for me.

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