I want to use fork to make multithread application for sockets and I would like to fork it to run in dameon mode.
Can I fork the forked program? With call fork I get 0 in result in child.
#Tsch : Balázs Csaba
Mailing lists / fpc-pascal / 2003-09
fork with forked program
9 messages · 5 people ·
- Jonas Maebe 2
- Marco van de Voort 2
- Matt Emson 2
- Michael Van Canneyt 2
- Balázs Csaba 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
I want to use fork to make multithread application for sockets and I would like to fork it to run in dameon mode.
Multithread is not possible with Fork()
Can I fork the forked program? With call fork I get 0 in result in child.
This is correct. Fork returns 0 in the child and returns the child process ID in the parent.
Michael.
Michael, forgive me if I am wrong - I am not a Unix buff - but I was under the impression that forking was a method for creating multithreaded unix apps?!? Everytime you fork() you end up with two seperate processes running concurrently. You differentiate between them by chacking the result given by fork(). Certainly under Cygwin this works. I also have some code written using POSIX calls on BeOS that creates a daemon by forking 3 times.
Matt
I want to use fork to make multithread application for sockets and I would like to fork it to run in dameon mode.
Multithread is not possible with Fork()
Can I fork the forked program? With call fork I get 0 in result in child.
This is correct. Fork returns 0 in the child and returns the child process ID in the parent.
Michael.
Matt Emson wrote 6 lines
Michael, forgive me if I am wrong - I am not a Unix buff - but I was under
the impression that forking was a method for creating multithreaded unix
apps?!? Everytime you fork() you end up with two seperate processes running
concurrently. You differentiate between them by chacking the result given by
fork(). Certainly under Cygwin this works. I also have some code written
using POSIX calls on BeOS that creates a daemon by forking 3 times.
Multithreaded applications share the same memory space. Forked applications are truly separate applications, they have a different memory space.
So the term 'multithreaded' doesn't apply. If you want to share the same memory space, you need the 'Clone' function in linux.
Michael.
Multithreaded applications share the same memory space. Forked applications are truly separate applications, they have a different
memory
space.
Got you. So the correct term would be 'multiprocess'. I always forget that UNIX considers processes to be seperate to threads. BeOS does things slightly differently. We have the notion of 'teams'. A thread belongs to a 'team'. All threads are effectively light weight processes. However, and I forget the exact reason, a team is not an exact equivilence to a UNIX process.
So the term 'multithreaded' doesn't apply. If you want to share the same memory space, you need the 'Clone' function in linux.
The wonders of 70's inspired technology ;-) Fork sounded sensible, but clone sounds a bit like it does something completely different. Ah well....
Matt
Matt Emson wrote 9 lines
Got you. So the correct term would be 'multiprocess'. I always forget
that
UNIX considers processes to be seperate to threads. BeOS does things
slightly differently. We have the notion of 'teams'. A thread belongs
to a
'team'. All threads are effectively light weight processes. However,
and I
forget the exact reason, a team is not an exact equivilence to a UNIX
process.
This has nothing to do with unix <-> BeOS. For example, Solaris is definitely Unix and also uses the concept of light weight processes. Different OS'es simply use different process models.
Jonas
Show quoted text 14 lines
On dinsdag, sep 16, 2003, at 14:55 Europe/Brussels, Matt Emson wrote:
> Got you. So the correct term would be 'multiprocess'. I always forget
> that
> UNIX considers processes to be seperate to threads. BeOS does things
> slightly differently. We have the notion of 'teams'. A thread belongs
> to a
> 'team'. All threads are effectively light weight processes. However,
> and I
> forget the exact reason, a team is not an exact equivilence to a UNIX
> process.
This has nothing to do with unix <-> BeOS. For example, Solaris is
definitely Unix and also uses the concept of light weight processes.
Light weight processes are a Unix feature.
(heavy and cheap are relative to the other)
Windows -> heavy processes, cheap threads.
Unix -> cheap processes, expensive threads
Moreover Windows schedules threads, doesn't even treat processes differently. Traditional unix didn't do this either, but several modern OSes (like FreeBSD 5 (KSE)) can.
Different OS'es simply use different process models.
The differences are classic, but just like many other points in the traditional unix vs mach kernel discussion, things are getting more blurred because of cross-pollination. (think messaging, kernel loadable modules, "special" kernel related servers in unix, moving of systems in kernel on mach kernels out of speed reasons)
Marco van de Voort wrote> This has nothing to do with unix <-> BeOS. For example, Solaris is > definitely Unix and also uses the concept of light weight processes. Light weight processes are a Unix feature.
Not all Unixes have light weight processes. Note that "light weight process" has nothing to do with whether or not it is cheap to start a new process on a particular OS.
(heavy and cheap are relative to the other) Windows -> heavy processes, cheap threads. Unix -> cheap processes, expensive threads
That is a vast over-generalisation. All unixes most definitely do not have expensive threads, in fact in several of them a process is always layered over a thread.
Jonas
Show quoted text 11 lines
On dinsdag, sep 16, 2003, at 15:34 Europe/Brussels, Marco van de Voort
wrote:
>> This has nothing to do with unix <-> BeOS. For example, Solaris is
>> definitely Unix and also uses the concept of light weight processes.
>
> Light weight processes are a Unix feature.
Not all Unixes have light weight processes. Note that "light weight
process" has nothing to do with whether or not it is cheap to start a
new process on a particular OS.
Google says about LWP: (FOLDOC)
A single-threaded sub-process which, unlike a thread, has its own process identifier and may also differ in its inheritance and controlling features.
It seems to be somewhere inbetween thread and full process. However what and how exactly the difference is, seems vague (specially since any process on Unix is a sub-process of init ?)
Show quoted text 5 lines
> (heavy and cheap are relative to the other)
> Windows -> heavy processes, cheap threads.
> Unix -> cheap processes, expensive threads
That is a vast over-generalisation.
It's the traditional definition. Threads were originally implemented userland. Only with System V they came into the kernel afaik.
However most free unices are BSD derived and kept their userland threading for a long while. This also because the userland threading remained the only portable threading.
All unixes most definitely do not have expensive threads, in fact in several of them a process is always layered over a thread.
Which is a deviation of the original concepts, and the raeson why I said that in most recent years the definitions are blurred.