Re: GNAT and Tasklets

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 18 Dec 2014 17:01:18 -0600, Randy Brukardt wrote:

> As I noted later, there should only be one task reading/writing the socket 
> at a time.

That might be OK for a server application, but clients must read and write
from socket concurrently. In a half-duplex scenario (client-server is) it
is highly advisable that one of the peers read and write simultaneously in
order to prevent deadlock. Consider a case when a peer tries to write when
another is reading. This may happen in half-duplex exchange on protocol
errors.

For full-duplex exchanges you simply must do it concurrently. There are
lots of full-duplex protocols over sockets. 

> That's of course especially true with a proper higher-level communications 
> library, since there almost certainly will be instance data that needs to be 
> protected against multi-access.

That is not a problem, usually. The states manipulated when reading and
ones upon writing are usually well insulated.

>> Having several I/O-processes makes it easy to change the
>> way of communication, and still have the same business logic.
>> (say an installation from 1992 talks Siemens 3964r/k512 over a serial
>> line (its a old standard protocol) and they want to switch plc's
>> which talks tcp/ip with another transmission protocol.
>> If keeping the messages within the protocol intact,
>> then it's just matter of a new I/O process.
>> The rest of the system is untouched including business logic processes.
>> (I just did this this spring)
> 
> I still think this sounds way too low-level.

Typical socket architecture is

1. Low-level I(O
2. Protocol stack(s)
3. Application logic

Any of 1-3 can be handled tasks taken from some workers pool.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de