Subject: RE: [SDLTF-Members] SDL-News: SAVE: Request for additional feedba ck
From: Frend Patrick-BPF005 (BPF005#motorola.com)
Date: Fri Jan 09 2004 - 17:22:18 GMT
Become an SDL Forum Society member <http://www.sdl-forum.org/Society/members.htm>
The originator of this message is responsible for its content.
-----From Frend Patrick-BPF005 <BPF005#motorola.com> to sdlnews -----
-----Original Message-----
From: Rick Reed TSE [mailto:rickreed#tseng.co.uk]
Sent: 09 January 2004 16:22
To: Frend Patrick-BPF005; sdlnews#sdl-forum.org
Subject: Re: [SDLTF-Members] SDL-news: SAVE: Request for additional
feedba ck
Frend Patrick-BPF005 at BPF005#motorola.com wrote on 01/08/04 17:43:
> It would be sensible semantics that the queue was flushed up to the signal
> that
> instigated the reset (E2). It's also very simple, easy to implement/understand
> and it doesn't preclude the inclusion of "save" or "priority input" etc.
Dear All,
This would be an additional feature for SDL - which is the point the William
was making.
However, every feature - even a small one - makes the language more complex
- the opposite of considering a well defined subset. I doubt that this is
needed frequently enough to to justify a language change.
In any case this particular feature CAN be implemented by buffering the
information internally. This is not really surprising, because it seems that
any manipulations of the input queue CAN be changed to copying the message
information into an internal buffer, and then doing the manipulations on
that internal buffer. Indeed this approach allows the queue to be
manipulated in ways NOT currently permitted the current SDL mechanisms for
consuming (not consuming) signals from the input queue (input, priority
input, enabling condition, spontaneous input, continuous signal and save).
To use this approach requires additional data and code in the application to
handle the internal buffering written using other SDL features (data types
such as SEQUENCE OF the message type (possibly a union CHOICE of messages),
variables of this type, manipulation of the variables ...).
Rick Reed - rickreed#tseng.co.uk
Tel:+44 15394 88462 Mob.:+44 7970 50 96 50
A very common usage of this would be for a protocol
that handles re-transmission of failed transmissions for
a reliable protocol.
If a flush were part of the language, combined with save,
this would be very simple.
Each time a signal is send over the protocol, it is also sent
to a re-transmission process, where the signal is saved.
If the ack is received, a signal is sent to this re-transmission
process, which then flushes it's input queue atomically. Else
after a timer, it processes the saved signals, for re-transmission.
Yes, this CAN be handled by the process queueing stuff internally,
I agree. The same goes for SAVE. The question should be is this a sensible
thing for the programmer to be thinking about. I.E. thinking about handling
queues rather than the problem domain.
Java took it's inspiration from a "Reduced" C++, but also provided new features
that significantly simplified the use of the language, by adding to the language.
If Save is removed, then either you double the number of states for each SAVE that is
needed, or you have a 2 tier input queue, where part of it is supported by the language
and part of it you have to implement repeatedly yourself. Handling an additional queue internally
leads to additional signalling needed to prompt the process into looking at the internal queue.
--End text from Frend Patrick-BPF005 <BPF005#motorola.com> to sdlnews ---
For extra SDL Forum Society benefits join at <http://www.sdl-forum.org/Society/members.htm>
This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:50 GMT