Task, process, thread, etc.

On 4/5/2021 23:44, Don Y wrote:
> On 4/5/2021 12:12 PM, Dimiter_Popoff wrote:
>> On 4/5/2021 8:29, Don Y wrote:
>>> On 4/4/2021 2:42 PM, Don Y wrote:
>>>
>>>> Yes, of course.  But, some things (objects) already have a
>>>> "naming history" that people are comfortable with.
>>>>
>>>> Call a thread an "execution unit"?  The processor on
>>>> which it executes an "executor unit"?&nbsp; <grin>
>>>>
>>>> Would it be strained to call a process a "Resource Container"?
>>>
>>> I floated that idea... and it was **promptly** shot down!
>>>
>>> Amusingly, folks like to talk about a process as if it is an
>>> active entity - even KNOWING that the process is the container
>>> FOR the active entities and not the executing code!
>>>
>>> And, the notion of using "Resource Container" in a sentence
>>> as if it was in any way "active" fell on deaf ears.
>>>
>>> <shrug>&nbsp; It's amusing to see the implicit baggage that comes
>>> with our choices of terms!
>>>
>>> (admit defeat; tweak the code/docs and be done with it!)
>>
>> I am not surprised at that :-). My reaction was similar.
> 
> Yes.&nbsp; But, amusing as the *container* isn't an active entity!
> Yet, we speak of it as if it was -- as a proxy for the threads
> it contains!
> 
> So, it's important that folks discussing an implementation
> have a shared lexicon; someone talking about "processes" may
> or may not be thinking in terms of "threads"!
> 
>> I call a "container" objects which have allocated the memory
>> for another object - so when an object is told to "getlost"
>> it asks its container to deallocate it apart from whatever
>> else it has to do (close file(s), connection(s) etc.).
>> But I think of "container" as of a jar with a lid you know.
>>
>> If I understand what you want to name is a group of tasks
>> (which you call threads); why not just call it "group of
>> tasks" or something. Then gradually let the language migrate towards
>> just "group"on its own, that is in a natural way.
> 
> It's not just a "group of threads"&nbsp; (trying to avoid mixing terms);
> it's a group of threads executing in an isolated address space sharing
> a set of capabilities for a set of objects and access to specific
> code/data...

OK, "container" may be the right word but to me (and apparently to
other people) it sounds more static than what you describe. I mean
subconsciously one thinks that a container has some static contents....
Call it an "aquarium", lol. On a second thought, it may do the job
exactly because it sounds funny....

Dimiter

On 4/5/2021 1:54 PM, Dimiter_Popoff wrote:
> On 4/5/2021 23:44, Don Y wrote:
>> On 4/5/2021 12:12 PM, Dimiter_Popoff wrote:
>>> I call a "container" objects which have allocated the memory
>>> for another object - so when an object is told to "getlost"
>>> it asks its container to deallocate it apart from whatever
>>> else it has to do (close file(s), connection(s) etc.).
>>> But I think of "container" as of a jar with a lid you know.
>>>
>>> If I understand what you want to name is a group of tasks
>>> (which you call threads); why not just call it "group of
>>> tasks" or something. Then gradually let the language migrate towards
>>> just "group"on its own, that is in a natural way.
>>
>> It's not just a "group of threads"  (trying to avoid mixing terms);
>> it's a group of threads executing in an isolated address space sharing
>> a set of capabilities for a set of objects and access to specific
>> code/data...
> 
> OK, "container" may be the right word but to me (and apparently to
> other people) it sounds more static than what you describe. I mean
> subconsciously one thinks that a container has some static contents....
> Call it an "aquarium", lol. On a second thought, it may do the job
> exactly because it sounds funny....

Yes, the container *is* static!  It's the threads that actually do work!
(wherever they may actually reside)

Yet, we talk about the process (i.e., container) as if *it* was
actually doing the work!  Imprecise language:  the threads IN the
process are doing the work.

We talk of "killing" a process (or "starting" a process) -- as if *it* was
an active entity.  But, what we really mean is to stop all of the threads
in the process (container), free all of their resources and then delete/destroy
the process (container).

On 4/6/2021 1:05, Don Y wrote:
> On 4/5/2021 1:54 PM, Dimiter_Popoff wrote:
>> On 4/5/2021 23:44, Don Y wrote:
>>> On 4/5/2021 12:12 PM, Dimiter_Popoff wrote:
>>>> I call a "container" objects which have allocated the memory
>>>> for another object - so when an object is told to "getlost"
>>>> it asks its container to deallocate it apart from whatever
>>>> else it has to do (close file(s), connection(s) etc.).
>>>> But I think of "container" as of a jar with a lid you know.
>>>>
>>>> If I understand what you want to name is a group of tasks
>>>> (which you call threads); why not just call it "group of
>>>> tasks" or something. Then gradually let the language migrate towards
>>>> just "group"on its own, that is in a natural way.
>>>
>>> It's not just a "group of threads"  (trying to avoid mixing terms);
>>> it's a group of threads executing in an isolated address space sharing
>>> a set of capabilities for a set of objects and access to specific
>>> code/data...
>>
>> OK, "container" may be the right word but to me (and apparently to
>> other people) it sounds more static than what you describe. I mean
>> subconsciously one thinks that a container has some static contents....
>> Call it an "aquarium", lol. On a second thought, it may do the job
>> exactly because it sounds funny....
> 
> Yes, the container *is* static!  It's the threads that actually do work!
> (wherever they may actually reside)
> 
> Yet, we talk about the process (i.e., container) as if *it* was
> actually doing the work!  Imprecise language:  the threads IN the
> process are doing the work.
> 
> We talk of "killing" a process (or "starting" a process) -- as if *it* was
> an active entity.  But, what we really mean is to stop all of the threads
> in the process (container), free all of their resources and then 
> delete/destroy
> the process (container).

So aquarium is not that bad,especially if we choose to call a
task a fish etc. :D.
While I don't think anybody (except perhaps me...) would find
"aquarium" an acceptable term, following that line of thought
a "bowl" might even be OK. You pour everything out of it and eventually
break it into pieces -> it goes into dust...

Dimiter

On 4/5/2021 3:14 PM, Dimiter_Popoff wrote:
> On 4/6/2021 1:05, Don Y wrote:

>> Yet, we talk about the process (i.e., container) as if *it* was
>> actually doing the work!  Imprecise language:  the threads IN the
>> process are doing the work.
>>
>> We talk of "killing" a process (or "starting" a process) -- as if *it* was
>> an active entity.  But, what we really mean is to stop all of the threads
>> in the process (container), free all of their resources and then delete/destroy
>> the process (container).
> 
> So aquarium is not that bad,especially if we choose to call a
> task a fish etc. :D.
> While I don't think anybody (except perhaps me...) would find
> "aquarium" an acceptable term, following that line of thought
> a "bowl" might even be OK. You pour everything out of it and eventually
> break it into pieces -> it goes into dust...

I'm going to stick with "process".  But, I'm going to include references
to how it is often "misused" in this way -- to clarify what is meant by
such misuse.

On 4/2/2021 6:46 PM, antispam@math.uni.wroc.pl wrote:
> ...  Significant
> part of my early experience was on ZX Spectrum: it had no
> hardware UART and it was pretty clear that to get characters
> you need to poll at right time, otherwise bits will be lost
> (I did not try real UART, but I played a bit with tape
> reading procedure).

Reminds me of early in my career, trying to write some assembly code to 
move data from an acoustic modem (you know, phone handset into rubber 
boots) onto an 8-track tape while dealing with some additional inputs, 
on a machine with no interrupts. As I was getting REALLY aggravated with 
dropped characters, a colleague came in and told me the acoustic modem 
only worked when turned on its side. I screamed at him I was in no mood 
for jokes and chased him out of there. And then I found out he was 
telling the truth and my code worked fine with the modem on its side...

Fortunately things have improved a bit since those days!

OK, back to work now.

On 16.4.21 23.39, Dave Nadler wrote:
> On 4/2/2021 6:46 PM, antispam@math.uni.wroc.pl wrote:
>> ...  Significant
>> part of my early experience was on ZX Spectrum: it had no
>> hardware UART and it was pretty clear that to get characters
>> you need to poll at right time, otherwise bits will be lost
>> (I did not try real UART, but I played a bit with tape
>> reading procedure).
> 
> Reminds me of early in my career, trying to write some assembly code to 
> move data from an acoustic modem (you know, phone handset into rubber 
> boots) onto an 8-track tape while dealing with some additional inputs, 
> on a machine with no interrupts. As I was getting REALLY aggravated with 
> dropped characters, a colleague came in and told me the acoustic modem 
> only worked when turned on its side. I screamed at him I was in no mood 
> for jokes and chased him out of there. And then I found out he was 
> telling the truth and my code worked fine with the modem on its side...
> 
> Fortunately things have improved a bit since those days!
> 
> OK, back to work now.


It may be a problem of the telephone handset. Older handsets used
the Edison carbon mic which needed to have the diaphgram vertical
to work well.

-- 

-TV

On 4/17/2021 4:21 AM, Tauno Voipio wrote:
> On 16.4.21 23.39, Dave Nadler wrote:
>> On 4/2/2021 6:46 PM, antispam@math.uni.wroc.pl wrote:
>>> ...  Significant
>>> part of my early experience was on ZX Spectrum: it had no
>>> hardware UART and it was pretty clear that to get characters
>>> you need to poll at right time, otherwise bits will be lost
>>> (I did not try real UART, but I played a bit with tape
>>> reading procedure).
>>
>> Reminds me of early in my career, trying to write some assembly code 
>> to move data from an acoustic modem (you know, phone handset into 
>> rubber boots) onto an 8-track tape while dealing with some additional 
>> inputs, on a machine with no interrupts. As I was getting REALLY 
>> aggravated with dropped characters, a colleague came in and told me 
>> the acoustic modem only worked when turned on its side. I screamed at 
>> him I was in no mood for jokes and chased him out of there. And then I 
>> found out he was telling the truth and my code worked fine with the 
>> modem on its side...
>>
>> Fortunately things have improved a bit since those days!
>>
>> OK, back to work now.
> 
> 
> It may be a problem of the telephone handset. Older handsets used
> the Edison carbon mic which needed to have the diaphgram vertical
> to work well.

Interesting! Maybe both the handset and coupler used that mic...

On 17.4.21 17.38, Dave Nadler wrote:
> On 4/17/2021 4:21 AM, Tauno Voipio wrote:
>> On 16.4.21 23.39, Dave Nadler wrote:
>>> On 4/2/2021 6:46 PM, antispam@math.uni.wroc.pl wrote:
>>>> ...  Significant
>>>> part of my early experience was on ZX Spectrum: it had no
>>>> hardware UART and it was pretty clear that to get characters
>>>> you need to poll at right time, otherwise bits will be lost
>>>> (I did not try real UART, but I played a bit with tape
>>>> reading procedure).
>>>
>>> Reminds me of early in my career, trying to write some assembly code 
>>> to move data from an acoustic modem (you know, phone handset into 
>>> rubber boots) onto an 8-track tape while dealing with some additional 
>>> inputs, on a machine with no interrupts. As I was getting REALLY 
>>> aggravated with dropped characters, a colleague came in and told me 
>>> the acoustic modem only worked when turned on its side. I screamed at 
>>> him I was in no mood for jokes and chased him out of there. And then 
>>> I found out he was telling the truth and my code worked fine with the 
>>> modem on its side...
>>>
>>> Fortunately things have improved a bit since those days!
>>>
>>> OK, back to work now.
>>
>>
>> It may be a problem of the telephone handset. Older handsets used
>> the Edison carbon mic which needed to have the diaphgram vertical
>> to work well.
> 
> Interesting! Maybe both the handset and coupler used that mic...


The traffic has to be bi-directional, so one bad mic is sufficient
to spoil the communication.

When I was a student, over half century ago, I worked for a telephone
company, and we had plenty of carbon mic phones with associated
problems, but no modems yet.

-- 

-TV