Re: dynamic multithreading

["AG" <ang@xtra.co.nz>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]


"Thierry Lelegard" <thierry.lelegard@canal-plus.fr> wrote in message
news:3DD3D841.CD16A4CB@canal-plus.fr...
> Bj�rn Lundin wrote:
> > If I remember correctly, there's an example of
> > a process action as server, listening for new connections.
> > For each new connection, a new task is created
>
> This is generally a bad design.

That's arguable.

>
> - First, there is performance issue. Creating a new task each time
>   a new connection comes in is a pain on heavily loaded servers.

Well, servers come and go, tech impoves or not but design stays.

>
> - Second, you must absolutely unchecked_deallocate each task after
>   it is terminated (not always trivial to synchronize on actual
>   termination of a task). Otherwise, you have a memory leak.

Which means you don't trust the run-time system to do some
elementary GC? If you are *that* paranoid (or have a good
reason to be) perhaps it's time to abandon Ada and switch
back to the good old Assembly language.

>
> As an alternative, never let a service task die. Once a task has
> finished servicing a connection, make it wait and reuse it for a
> later connection.

Yuck. That means the task needs to be able to reset to a clean
state anytime it's finished with a connection. It would also need
to handle all possible error conditions and abnormal ends to be
able to come back on line "up and ready". It's much much cleaner
to just let the task die and start from scratch. (Hey, how many
projects agonized like that for years instead of just restarting
at a good time?) That does not include the safety-critical systems,
of course, just the common "run of the mill" things.

> This is not so difficult to design and much more robust.

I'd disagree. It is much easier to design a system which
always starts from scratch. There is also a lot less potential
for errors since you don't need to keep or handle previous
states. So how can it be less robust? (Unless, as stated above,
you simply don't trust your run-time system to even de-allocate
the stack)