Threads share resources such as address space, files, etc. A process
runs in its own address space. (at least these days, before virtual >>memory, who knows?)
With copy-on-write process models the actual difference is a bit less
clear cut.
According to <boltar@caprica.universe>:
Threads share resources such as address space, files, etc. A process >>>runs in its own address space. (at least these days, before virtual >>>memory, who knows?)
With copy-on-write process models the actual difference is a bit less
clear cut.
Copy-on-write (or on some older systems copy-on-touch) is an implementation >detail. Neither process can look inside the other even if they share some >unwritten or untouched pages.
On Sun, 25 Oct 2026 18:17:44 -0000 (UTC)
John Levine <johnl@taugh.com> gabbled:
According to <boltar@caprica.universe>:
Threads share resources such as address space, files, etc. A process
runs in its own address space. (at least these days, before virtual
memory, who knows?)
With copy-on-write process models the actual difference is a bit less
clear cut.
Copy-on-write (or on some older systems copy-on-touch) is an implementation >> detail. Neither process can look inside the other even if they share some >> unwritten or untouched pages.
The point is they are sharing memory. In a reference implementation processes don't share any virtual memory at all - everything is copied to a new location
at fork - so you can't use sharing memory as a way to demarcate multithreading
and multiprocess.
On 10/26/26 02:57, boltar@caprica.universe wrote:
On Sun, 25 Oct 2026 18:17:44 -0000 (UTC)
John Levine <johnl@taugh.com> gabbled:
According to <boltar@caprica.universe>:
Threads share resources such as address space, files, etc. A process >>>>> runs in its own address space. (at least these days, before virtual
memory, who knows?)
With copy-on-write process models the actual difference is a bit less
clear cut.
Copy-on-write (or on some older systems copy-on-touch) is an implementation >>> detail. Neither process can look inside the other even if they share some >>> unwritten or untouched pages.
The point is they are sharing memory. In a reference implementation processes
don't share any virtual memory at all - everything is copied to a new location
at fork - so you can't use sharing memory as a way to demarcate multithreading
and multiprocess.
In the old days before IUCV or VMCF I did a multi-process application on
VM by using a file to pass data among processes. Surprisingly, it worked >well.
Peter Flass <Peter@Iron-Spring.com> writes:
On 10/26/26 02:57, boltar@caprica.universe wrote:
On Sun, 25 Oct 2026 18:17:44 -0000 (UTC)
John Levine <johnl@taugh.com> gabbled:
According to <boltar@caprica.universe>:
Threads share resources such as address space, files, etc. A process >>>>>> runs in its own address space. (at least these days, before virtual >>>>>> memory, who knows?)
With copy-on-write process models the actual difference is a bit less >>>>> clear cut.
Copy-on-write (or on some older systems copy-on-touch) is an implementation
detail. Neither process can look inside the other even if they share some >>>> unwritten or untouched pages.
The point is they are sharing memory. In a reference implementation processes
don't share any virtual memory at all - everything is copied to a new location
at fork - so you can't use sharing memory as a way to demarcate multithreading
and multiprocess.
In the old days before IUCV or VMCF I did a multi-process application on
VM by using a file to pass data among processes. Surprisingly, it worked
well.
Burroughs had both a synchronous 'core2core' interface between processes
as well as asynchronous storage queues. In the days of small address spaces, those were invaluable interfaces.
On 10/26/26 02:57, boltar@caprica.universe wrote:
On Sun, 25 Oct 2026 18:17:44 -0000 (UTC)
John Levine <johnl@taugh.com> gabbled:
According to <boltar@caprica.universe>:
Threads share resources such as address space, files, etc. A process >>>>> runs in its own address space. (at least these days, before virtual
memory, who knows?)
With copy-on-write process models the actual difference is a bit less
clear cut.
Copy-on-write (or on some older systems copy-on-touch) is an implementation >>> detail. Neither process can look inside the other even if they share some >>> unwritten or untouched pages.
The point is they are sharing memory. In a reference implementation processes
don't share any virtual memory at all - everything is copied to a new >location
at fork - so you can't use sharing memory as a way to demarcate >multithreading
and multiprocess.
In the old days before IUCV or VMCF I did a multi-process application on
VM by using a file to pass data among processes. Surprisingly, it worked >well.
On Mon, 26 Oct 2026 03:53:45 -0700
Peter Flass <Peter@Iron-Spring.com> gabbled:
On 10/26/26 02:57, boltar@caprica.universe wrote:
On Sun, 25 Oct 2026 18:17:44 -0000 (UTC)location
John Levine <johnl@taugh.com> gabbled:
According to˙ <boltar@caprica.universe>:
Threads share resources such as address space, files, etc. A process >>>>>> runs in its own address space. (at least these days, before virtual >>>>>> memory, who knows?)
With copy-on-write process models the actual difference is a bit less >>>>> clear cut.
Copy-on-write (or on some older systems copy-on-touch) is an
implementation
detail.˙ Neither process can look inside the other even if they
share some
unwritten or untouched pages.
The point is they are sharing memory. In a reference implementation
processes
don't share any virtual memory at all - everything is copied to a new
at fork - so you can't use sharing memory as a way to demarcatemultithreading
and multiprocess.
In the old days before IUCV or VMCF I did a multi-process application
on VM by using a file to pass data among processes. Surprisingly, it
worked well.
I'd be interested how you'd implement fork() using that method given you
need to copy the state of all file descriptors, heap, stack and global memory, current working directory, enviroment variables and a ton of other things I can't remember without googling.
On Mon, 26 Oct 2026 03:53:45 -0700
Peter Flass <Peter@Iron-Spring.com> gabbled:
On 10/26/26 02:57, boltar@caprica.universe wrote:
On Sun, 25 Oct 2026 18:17:44 -0000 (UTC)location
John Levine <johnl@taugh.com> gabbled:
According to˙ <boltar@caprica.universe>:
Threads share resources such as address space, files, etc. A process >>>>>> runs in its own address space. (at least these days, before virtual >>>>>> memory, who knows?)
With copy-on-write process models the actual difference is a bit less >>>>> clear cut.
Copy-on-write (or on some older systems copy-on-touch) is an
implementation
detail.˙ Neither process can look inside the other even if they
share some
unwritten or untouched pages.
The point is they are sharing memory. In a reference implementation
processes
don't share any virtual memory at all - everything is copied to a new
at fork - so you can't use sharing memory as a way to demarcatemultithreading
and multiprocess.
In the old days before IUCV or VMCF I did a multi-process application
on VM by using a file to pass data among processes. Surprisingly, it
worked well.
I'd be interested how you'd implement fork() using that method given you
need to copy the state of all file descriptors, heap, stack and global memory, current working directory, enviroment variables and a ton of other things I can't remember without googling.
On 10/26/26 09:19, boltar@caprica.universe wrote:
On Mon, 26 Oct 2026 03:53:45 -0700
Peter Flass <Peter@Iron-Spring.com> gabbled:
On 10/26/26 02:57, boltar@caprica.universe wrote:
On Sun, 25 Oct 2026 18:17:44 -0000 (UTC)location
John Levine <johnl@taugh.com> gabbled:
According to˙ <boltar@caprica.universe>:
Threads share resources such as address space, files, etc. A process >>>>>>> runs in its own address space. (at least these days, before virtual >>>>>>> memory, who knows?)
With copy-on-write process models the actual difference is a bit less >>>>>> clear cut.
Copy-on-write (or on some older systems copy-on-touch) is an
implementation
detail.˙ Neither process can look inside the other even if they
share some
unwritten or untouched pages.
The point is they are sharing memory. In a reference implementation
processes
don't share any virtual memory at all - everything is copied to a new
at fork - so you can't use sharing memory as a way to demarcatemultithreading
and multiprocess.
In the old days before IUCV or VMCF I did a multi-process application
on VM by using a file to pass data among processes. Surprisingly, it
worked well.
I'd be interested how you'd implement fork() using that method given you
need to copy the state of all file descriptors, heap, stack and global
memory, current working directory, enviroment variables and a ton of
other
things I can't remember without googling.
No fork. Each VM had a single thread of execution. I was happy to get multiple processes to cooperate. It was a master process (virtual
machine) that distributed work to worker machines.
In the old days before IUCV or VMCF I did a multi-process application
on VM by using a file to pass data among processes. Surprisingly, it
worked well.
On 10/26/2026 9:19 AM, boltar@caprica.universe wrote:
I'd be interested how you'd implement fork() using that method given you
need to copy the state of all file descriptors, heap, stack and global
memory, current working directory, enviroment variables and a ton of other >> things I can't remember without googling.
Why even do that? Sigh.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 5 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 232:41:02 |
| Calls: | 221 |
| Files: | 21,513 |
| Messages: | 84,424 |