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


On Thu, 22 Aug 96 19:49:46 G Guy Harrison <test@swampd wrote: 
>
>Peter, Ronald,

Present, Guy!  (Well I am at least. I'll let Peter speak for himself.)


----- snip -----
snipped code showed direct STiK flag testing mixed with evnt_multi call
in a suggested standard way for future/improved STiK clients...
----- snip -----

>A slight modification opens up many possibilities (I've been up 36 
>hours so please take this into account :-) ...
>
>uint
>Evnt_Multi(struct evnt_multi *ep, bool aes_flag)
>{int	len;
>
> ep->events_occured = NONE;
> 
>/* number of bytes to receive or zero */
>/* allows app possibility to change size of its receive buffer */
> if (len = is_msg(apid))	{
> 
>	/* len = num_left on exit */
>	num_left = read_msg(apid,&len,ep->msgbuf);
>	/* allows app possibility to keep its receive buffer static and */
>	/* shift the received data to wherever it sees fit in an easy */
>	/* "while (read_msg(.,&len,.) memcpy(.,ep->msgbuf,len)" loop */
>
>	ep->events_occured |= MU_MESAG;
>
>/* optional AES overhead */
> if (aes_flag)	ep->events_occurred |= evnt_multi(...);
>
> return ep->events_occurred;
>}
>
>This looks promising. The app is forced to read (and thus clear)  the 
>message at some point, but the programmer is completely free to decide 
>when because testing the presence of a message does not clear it. ie, 
>there is no requirement to do it next to evnt_multi().
>
>The obvious advantage is it can be made transparent to the app's 
>MU_MESAG handler.

Perhaps I misunderstood part of the above, but it seems you want real AES messages
to actually transfer the data itself.  That would mean we lose control over when
it gets done, since there is no message priority system.

If there are some screen redraws preceding the STiK message, then they will have
to be handled (each found by a separate event function call) before we can get to
the STiK message and then transfer the data.

If you mean simulating message reception, by setting flags etc as if such had
occurred, but actually basing this upon STiK flag tests, then I'm with you,


>Intimate STiK programs could take advantage of the speed, even for 
>sending themselves redraw messages etc, it having exactly the same 
>effect as appl_write(). Equally important, anything implemented like 
>this would also be available to a STiK unaware application via 
>appl_write - could be very important in the future.

I must have misunderstood something, because things sent with 'appl_write'
can't be relied upon to arrive with satisfactory speed.  Please clarify.

I think you mean that we could define message codes, but not normally use the
AES message system to send them, preferring faster means of doing it.
Future applications would, however, have the option of doing so,
although that might then diminish their effective speed.


>It might be worth splitting up is_msg() into two parts - 
>is_first_msg() and is_next_msg() in much the same way as Fsfirst(), 
>Fsnext(). This would allow one threaded code section to quickly 
>control another thread because the controlled thread can be selective 
>in the messages it looks for, leaving unwanted messages for later 
>processing by some other part. At the very least, a data transfer 
>between two programs could be easily controlled.

The first/next approach may indeed be useful regardless of what method is used
for the actual transfer of data segments.  Especially to avoid locking things
during transfer of large amounts of data.

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