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

[Ada BRL <ada.brl.2011@gmail.com>]

On 24 Gen, 18:43, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> 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.

So, please tell me if I'm right, the server has to implement inside
itself the N output socket connections and I just need to have N tasks
implementing a socket connection each useful just for reading data
from the net and forwarding it to 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.

Are you referring to the tasks reading from the net?


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?

So I don't have to use tasks neither for reading? Sorry but I haven't
got the concept...

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.

The writers just receive data from the server and send it over the
net... now I recognize it's not a well designed software... :-(...

Just to see if I have understood everything:

- NO "writers tasks",
- N "readers tasks": every task has just one connection (socket) to
the peer from which receives data,
- Server is connected (by sockets) to N clients to which sends data
after elaboration,
- Server has one entry like: entry Receive_Data(Id_Reader_task : in
Integer; Data : in String), and inside its infinite loop accept this
entry,
- the generic "reader task" i calls the entry of the server like:
Server.Receive_Data(i, data);

Thank you very much!
You have "opened my eyes"!

>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de