To: stik@ON-Luebeck.DE
Subject: Re: [12] STIK: Runtime error Ag                                                 


On Fri, 11 Oct 1996 13:58:46 Peter Rottengatter <perot wrote: 
>
>On Fri, 11 Oct 1996, Ronald Andersson wrote:

----- snip ----->> > re: AESPB copying methods

>Sorry, bad wording. I was thinking about the AESPB to include the arrays. 
>Of course, the AESPB and the arrays must be copied. I would even use a 
>copy of the global array, because if some program manipulates the global 
>array in an improper way it would only be that program that would get 
>terminated by AES. Otherwise (if only the global pointer is used) all 
>programs using the same copy of global will crash.

That's true, and hopefully it is only the content of 'global' that matters
to AES in indentifying an APP.


----- snip ----->> >> re: need of AES capability

>STiK doesn't need AES capability if there is no GEM based client.

Perhaps not, but if it does have some, that may be shared with other modules
including non-GEM TSRs.


----- snip ----->> re: dialer mandatorily resident

>Many people want to save as much memory as possible, so they want to 
>terminate the Dialer after the connection is there. So I do not want 
>to force the Dialer to be used in a resident way.

Ok, I see your point, since the dialer has lots of stuff that we do not really
need to be resident.


>If there is really a separate GEM client needed, I could put this in both 
>the Dialer and a small, dedicated accessory, so that people can choose to 
>terminate the Dialer and use that small accessory instead. But I'd do 
>this as the last resort.

Pure duplication always feels useless, but that doesn't always make it so.
Even so, it would probably be better to include such routines in the INETD.ACC
you suggest in another mail.


----- snip ----->> >> re: Multitasking TOS function reentrancy

>> No, AFAIK only MagiC has such a rewrite of GEMDOS, but none of the other
>> multitaskers, and (also AFAIK) not even MagiC has interrupt-reentrant AES.
>> Besides, do you mean we should abandon single-tasking compatibility...?
>
>No, I just wanted to point out that this wasn't fully correct ;-)

True, but speaking of _all_ the AES versions no single description is.


>Concerning your other suggestion. I do not like very much the idea of 
>having two different schemes for the same goal. I do not have problems 
>with callback functions not being allowed to do certain system calls.
>There are always ways to get around this, it is only a matter of client 
>programming, say, by setting a flag so that the main evnt_multi can 
>do the call, or by just manipulating client data in the callback and 
>let the redraws be done by the main routines again. It is not the most 
>straight-forward way of programming, but it works well, and just needs a 
>little adjustment of programming skills to it.

I take it from this that you are in favor of having an interrupt-driven
callback scheduler, but that you do not want an event-driven one.

Actually the dominant reason I suggested the event-driven one was that this
would ensure the use of a common routine to call evnt_multi with MU_TIMER,
so that extreme optimization would benefit all clients/modules automagically.
They could still have their own 'evnt_multi' calls of course, but those would
never use MU_TIMER, since such needs would be handled by the scheduler.

Thus the other event types should never affect or be affected by timer events,
since from the AES point of view these would occur in different processes.

Another benefit of this scheduler is that when several clients/modules coexist
they do not need to use timer events in their separate evnt_multi calls, since
the scheduler handles this for all of them in its single evnt_multi call.
This could lead to significantly lower overheads with parallel clients.

I'm only clarifying these points in case you should have missed some of the
possibilities offered by a common event-driven scheduler.  If you still remain
convinced that it is a bad idea, I won't argue the matter further.


>However, there might be other reasons that will force us to have another 
>scheme.

That's always possible, but we'll deal with those when they come up.
In the meantime we have to plan as well as possible from current facts.

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