> 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
Reply by Dave Nadler●April 17, 20212021-04-17
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...
Reply by Tauno Voipio●April 17, 20212021-04-17
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
Reply by Dave Nadler●April 16, 20212021-04-16
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.
Reply by Don Y●April 5, 20212021-04-05
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.
Reply by Dimiter_Popoff●April 5, 20212021-04-05
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
Reply by Don Y●April 5, 20212021-04-05
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).
Reply by Dimiter_Popoff●April 5, 20212021-04-05
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"? <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> 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. 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" (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
Reply by Don Y●April 5, 20212021-04-05
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"? <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> 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. 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" (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...
[By contrast, a (non-specific) "group of threads" can span multiple
"processes" to solve a particular problem (hence "job").]
It is the sharing and coupling of the threads in that "container" to
which you want to draw attention. E.g., two such threads can stomp on
each other's data -- hence the need for mutexes/locks or some other
cooperative sharing algorithm. Two such threads can access the same
set of resources (e.g., thread A can acquire a resource yet thread B
can actually be the one who uses it without the need for any special
"protocol" to exchange "ownership"). In the context of an object
server, *any* thread *could* service a request for any object contained
in its "process"; or, specific threads could be assigned to specific
objects' requests; etc. But, a thread in ANOTHER *process* couldn't
service that request (for THAT object)!
*Within* a process, you have to be more disciplined, as a developer.
But, you have greater leeway in terms of what you can do -- and get
away with! The OS isn't playing policeman *inside* the process as it
would *between* processes. Communication can be nearly instantaneous;
you just agree as to how each thread will access a particular shared
structure/buffer. No need for the OS to get involved in moving
information across protection boundaries. All threads in a process
are colocated on the same *host*.
OTOH, a "group of threads" (cuz threads are the only things that
actually *do* anything!) executing in different processes can reside
on different hosts to achieve a common goal.
It's all the hidden assumptions (what I call baggage) that leads
to misunderstanding. If you have to resort to overly precise
language, then it becomes difficult reading. :< Hence, trying to
find terms that "feel" natural to people.
If I was describing a particular *algorithm* (that is likely to
evolve, over time), I could be a bit looser in my prose. But,
when discussing fundamentals (which are likely invariant), there's
less wiggle room. If I say "5", I mean *5*... not 4 or 6!
<shrug> I'll post you a draft copy when I get some of the
illustrations finished (busy picking oranges this past week+)
Reply by Dimiter_Popoff●April 5, 20212021-04-05
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"? <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> 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.
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.
Dimiter