Re: "C - like: THIS" pointer to a task type inside a task function

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

On Tue, 24 Jan 2012 09:12:03 -0800 (PST), Ada BRL wrote:

> On 23 Gen, 19:59, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Mon, 23 Jan 2012 11:32:39 -0800 (PST), Ada BRL wrote:
>>> I've N clients and one server that communicate each other.
>>> The N clients retrieve data dynamically, send it to the server throgh
>>> enrty call (obviously the server can accept just one call per time)
>>> and wait for the reply from the server (through accept statement).
>>
>> A server cannot wait for itself either "through accept statement" or any
>> other way.
>>
>> � �T4.Send_Data (Data);
>> � �accept Retrieve_Data (Data);
>>
>> is a patented way to run into a deadlock.
>>
> yes...you are right ... sorry ... =( BUT I MADE A MISTAKE!!!
> 
> There are two tasks for every communication channel:
> - one performing input, so retrieving data from the net and sending it
> to the server (call it T1_IN, T2_IN, ...)
> - one performing output, so retrieving data from the server and
> sending it on the net (call it T1_OUT, T2_OUT, ...)

OK. When you are working with sockets you normally do not need a dedicated
output task. The network stack is already buffered and most likely
asynchronous to the sender once you have initiated send. Thus you could
consider sending data straight out of the server. Note also that unless you
have a relatively small number of sockets to handle (a dozen or so), a task
per socket doing blocking read would not scale. Tasks are used to read
sockets simply because it is easier to program this way. If you have 2-3
sockets, why bother with asynchronous socket I/O? But you won't likely get
a better performance in terms of data throughout and latencies with
separate reader/writer tasks. Having one server engaging rendezvous with
writers that would make this design even less reasonable. That is because
you have the jobs *serialized* in the server. Writers will be either idle
most of the time waiting for the server or else block server, which would
want to make a rendezvous with a *concrete* writer each time. You would
gain nothing from parallelism here, because serialization of processing is
enforced by server, it only appears parallel. Unless there is some
considerable post-processing in the writers, it would rather eat
performance on meaningless task switching.

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