From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,2afbf99c1f65cbe
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.224.219.205 with SMTP id hv13mr5953511qab.5.1344263792934;
        Mon, 06 Aug 2012 07:36:32 -0700 (PDT)
Received: by 10.180.103.197 with SMTP id fy5mr1189428wib.1.1344263792863;
        Mon, 06 Aug 2012 07:36:32 -0700 (PDT)
Path: 
 c6ni64817200qas.0!nntp.google.com!u3no3271804qai.0!news-out.google.com!q11ni72566922wiw.1!nntp.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.panservice.it!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Sharing a socket connection
Date: Tue, 31 Jul 2012 14:09:09 +0200
Organization: cbb software GmbH
Message-ID: <1injxfyfr9r4s.h6s5ke4ev9un$.dlg@40tude.net>
References: <87hasofgwa.fsf@adaheads.sparre-andersen.dk>
 <16x1nvmt3gznc$.15s7zskookawr$.dlg@40tude.net>
 <87pq7c6tfc.fsf@adaheads.sparre-andersen.dk>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: 9A8bJrx4NhDLcSmbrb6AdA.user.speranza.aioe.org
Mime-Version: 1.0
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1
X-Notice: Filtered by postfilter v. 0.8.2
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: 2012-07-31T14:09:09+02:00
List-Id: <comp.lang.ada>

On Tue, 31 Jul 2012 13:50:31 +0200, Jacob Sparre Andersen wrote:

> Dmitry A. Kazakov wrote:
>> Jacob Sparre Andersen wrote:
> 
>>> The socket connection is bidirectional with requests sent from a
>>> client followed by corresponding responses from the server.  Each
>>> client should only get responses to its own requests.
>>
>> This sort of multiplexing will be extremely slow. Basically you block
>> communication until server respond.
> 
> Yes.  Fortunately that is not likely to be a problem for this
> application.

Then I would do just what Niklas suggested.

>> My primary concern would making it full duplex multiplexed. Because
>> half-duplex communication is really one of the major performance
>> killers.
>>
>> I would consider a request [protected] object queued to a dedicated
>> task doing I/O. The object would be waitable for the task that queued
>> it. Which is basically how OS drivers work.
> 
> I'm not sure I understand what you mean.  AFAIK protected objects can't
> queue on entries.

Protected object is basically a signal. You can pass it to a task entry or
queue somewhere. The "driver" picks up a request and initiates I/O (e.g.
sends something to the server). Then it shoves the request to another
queue. Upon receipt, which is typically another task, the task takes the
request and signals it completed. The caller may see nothing of these
transitions just waiting for the event signaled.

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