Re: Structure of the multitasking server

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

On Tue, 23 Sep 2008 01:07:38 -0700 (PDT), Maciej Sobczak wrote:

> I don't like it, because it misuses exceptions for something that is a
> perfectly normal control flow.

I don't know how a control flow can be abnormal. If "normality" is
attributed to the meaning of program's artefacts, then that is at the
programmer's discretion. Is it normal not to have a job? For a worker that
might look abnormal, for a welfare receiver it maybe not...

> Yes, this is very subjective - for the record, I also don't like the
> End_Error exception.

But you certainly enjoy Constraint_Error... It is not subjective, it is
unrealistic.
 
> BTW - the fact that you raise an exception only to shut it up in the
> same scope indicates that this is a severe misuse of some language
> feature.

I use this language feature in order to express "not a value" in a
type-safe way. The same feature is used when an integer overflows.

You didn't want "no job" become a job, so I used exceptions instead. (A
return flag with a rubbish value is not an Ada way.)

>>> In the version with protected objects the entity that triggers
>>> termination might be different from the one that invents job.
>>> In your version these different responsibilities are mixed.
>>
>> It does not work. You cannot selectively call to multiple entries of a
>> protected object anyway.
> 
> I don't have to. What I said is that the entities that provide jobs
> and that trigger termination can be different, not that the worker can
> get them from separate channels.

If entries are different then the worker cannot selectively call to them.
If they are never called by it, then how is this related to the worker? In
your code there was only one entry called by the worker.

>> Then again, termination should be triggered by
>> task finalization
> 
> Why? Which task?

The worker task.

>>> In particular, in my version the task that
>>> invents jobs is never blocked on interactions with workers. This is a
>>> big advantage, because such a blocking would disturb its own
>>> interactions with the environment and reduce its responsiveness.
>>
>> This is a design fault. Under certain conditions it must either block or
>> fail.
> 
> Where is the design fault? The immediate failure (as opposed to
> blocking) can be a valid overload handling policy.

First you said that it neither blocks nor fail. Now you consider it to fail
immediately. Fine, let's take this. Why then to queue jobs, which are known
to fail later? (It is difficult to pursue a moving target...)

>>> In your version with rendezvous the task that invents jobs has to
>>> block and during that time it cannot react to the events that drive it
>>> (keyboard input, network transmission, etc.).
>>
>> Wrong, see 9.7.1(16).
> 
> Again: keyboard input, network transmission, etc. Select statement is
> not flexible enough.

1. The selective accept statement is flexible enough. And in any case it is
far more flexible than entry call statements. This is one of the reasons
why rendezvous might be better in one to many relationships.

The problem with the things you mentioned is that their interfaces are not
conform to Ada tasking. There are many reasons for this, unrelated to the
discussion.

2. Not all interfaces are like those.

3. In this particular case the server can block on job reception, because
this is the only event to react to.

>> Your design is when a multicasting
>> publisher "knows" its peers. This is a bad idea, obviously.
> 
> Why it is a bad idea? What is bad in the manager having knowledge
> about workers in his team?

Yes, obviously. This requires a team and maintenance of. Such managers are
expensive and exposed to various risks. It might appear the only way of
design when you deal with humans, but fortunately, with bits and bytes
there are much better options.

> Is your boss aware of you or do you need to constantly ask him for new
> tasks?

This is a model widely used when you don't want to employ staff
permanently. If you have plenty of free workers, you just sit and wait them
to come. Fee is paid per work made. See freelances, etc.

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