Program creating many threads

[Чебурашка]

Hi
@Чебурашка: Thank you for doing the research, I just learned a new thing about threads/threadprogramming, and pretty important too 
Regards Benny

Countelss times I been helped by other users of forums.

In italian we say "E' una ruota che gira" (literally "It's a spinning wheel")

[alpine]

@Alpine et al... I was wondering about (lack of) synchronisation on termination after I posted last, but have been away from my desk. That sort of thing /should/ show up as a ballooning number of entries in /proc, since my understanding is that a Linux thread is a cloned (as distinct from forked) process.

Please explain: cloned vs forked.

AFAIK, forking (of a process) is when it starts like a single one, but eventually:

Code: C  [Select][+][-]

1.   ...
2.   if (fork() == 0)
3.   {
4.     // do the child work
5.   } else {
6.     // parent continued ...
7.   }
8.  

[Чебурашка]

@Alpine et al... I was wondering about (lack of) synchronisation on termination after I posted last, but have been away from my desk. That sort of thing /should/ show up as a ballooning number of entries in /proc, since my understanding is that a Linux thread is a cloned (as distinct from forked) process.

Please explain: cloned vs forked.

AFAIK, forking (of a process) is when it starts like a single one, but eventually:

Code: C  [Select][+][-]

1.   ...
2.   if (fork() == 0)
3.   {
4.     // do the child work
5.   } else {
6.     // parent continued ...
7.   }
8.  

I think MarkMLI is saying that in linux when you call fork, a new process is created by cloning the original = an exact copy of the process descriptor is made and assigned to the forked process (except the pid and ppid)

[MarkMLl]

I think MarkMLI is saying that in linux when you call fork, a new process is created by cloning the original = an exact copy of the process descriptor is made and assigned to the forked process (except the pid and ppid)

No, I am not. These are different system calls, and the distinction is critical to the way pthreads are implemented.

fork creates a new process with a distinct memory context, subject to COW. clone creates a new process sharing the came memory context, i.e. a thread.

The PID situation appears... messy in the TThread context, with the owning process's PID becoming the thread group and the subsidiary threads' PID becoming the thread identifiers. It might be that the BeginThread() return value is significant here.

MarkMLl

[alpine]

fork creates a new process with a distinct memory context, subject to COW. clone creates a new process sharing the came memory context, i.e. a thread.

I see.

But isn't it that the main difference between processes and threads - the former gets a copy of the parent data and the latter - just a private stack space (and CPU/FPU context)?

[MarkMLl]

But isn't it that the main difference between processes and threads - the former gets a copy of the parent data and the latter - just a private stack space (and CPU/FPU context)?

Yes, but the point is that "fork" and "clone" are "terms of art" here and shouldn't be (ab)used lightly.

I admit that from the POV of implementing an OS I far prefer the progression coroutine (AKA fiber etc.) -> thread -> process. But the fact of the matter is that in the context of Linux things are enormously constrained by POSIX and (using 1980s terminology) GLX, and changing subsystem architecture is incredibly and increasingly difficult: you've only got to look at the problems caused by the attempted transition from X11 to Wayland.

And I'd add at this point that I don't think that things are helped by Lennart Poettering's attempts to introduce complex subsystems like systemd and PulseAudio which operate at multiple levels in parallel with the Linux kernel, rather at distinct layers as is traditional.

MarkMLl