hello guys,
i am now ready to start the process management for my OS. I expect u guys to give some basic ideas for starting the process management with multitasking.
Process management - Getting Started
Re:Process management - Getting Started
I hate to be rude, but this topic has appeared here an infinite number of times, and all times in the past we've completely answered the question, up to almost all sideways possible. Please please search the forum or quicklinks. It IS there.
Just for kicks tried searching on "Multitasking" myself...
http://www.mega-tokyo.com/forum/index.p ... 25;start=0
http://www.mega-tokyo.com/forum/index.p ... 92;start=0
http://www.mega-tokyo.com/forum/index.p ... 46;start=0
http://www.mega-tokyo.com/forum/index.p ... 23;start=0
http://www.mega-tokyo.com/forum/index.p ... 61;start=0
http://www.mega-tokyo.com/forum/index.p ... 28;start=0
Just for kicks tried searching on "Multitasking" myself...
http://www.mega-tokyo.com/forum/index.p ... 25;start=0
http://www.mega-tokyo.com/forum/index.p ... 92;start=0
http://www.mega-tokyo.com/forum/index.p ... 46;start=0
http://www.mega-tokyo.com/forum/index.p ... 23;start=0
http://www.mega-tokyo.com/forum/index.p ... 61;start=0
http://www.mega-tokyo.com/forum/index.p ... 28;start=0
-
BI lazy
Re:Process management - Getting Started
Hi, Rahman: I think, what you are expecting might fill several books, and still it wouldn't do a better job than asking in a more polite way. But I s'pose, this tone of yours stems from a certain lack of words in english - isn't your native lingo, is it? Neither is it mine.
But pay attention, lad: first, check out the quicklinkz section.
second, check out www.distantvoices.org/html/multitasking.html. It might help.
third, go to www.osdever.net (dunno whether it's online again...)
and last but not least stay safe and don't pay too much attention to those who think posing a question is worth shoving their butts into your face.
a chinese proverb states:
the one who asks, is a fools for five minutes.
the one who never asks, is a fool forever.
But pay attention, lad: first, check out the quicklinkz section.
second, check out www.distantvoices.org/html/multitasking.html. It might help.
third, go to www.osdever.net (dunno whether it's online again...)
and last but not least stay safe and don't pay too much attention to those who think posing a question is worth shoving their butts into your face.
a chinese proverb states:
the one who asks, is a fools for five minutes.
the one who never asks, is a fool forever.
-
Rahman
Re:Process management - Getting Started
Thank u BI Lazy. I think most think that a newbie needs is a good encouragement & also a little bit discouragement 
. I have got both by posting this message.
. I have got both by posting this message.-
mrd
Re:Process management - Getting Started
Anyone care to comment on process ownership hierarchy? I don't see this mentioned anywhere. What are the purposes of it? How is it useful? Real-world examples.
Off the top of my head, some uses:
Children processes die when parent dies
Rights to modify scheduling priority of child processes
Rights to restrict access of child processes (file io, ipc, network)
Example: web-server spawning CGI children processes
Off the top of my head, some uses:
Children processes die when parent dies
Rights to modify scheduling priority of child processes
Rights to restrict access of child processes (file io, ipc, network)
Example: web-server spawning CGI children processes
-
Tim
Re:Process management - Getting Started
I think these all come under the heading of job control. In the general case you wouldn't want these behaviours to apply: imagine starting an app from a shell, then exiting the shell. To have all the shell's children die when the shell exits would be a bad thing.
However, you could designate processes as being part of a specific job. A default job would be created when you log in; this job holds all the processes that the interactive user starts. When the web server daemon starts, it creates a job and adds itself to it. From then on, all processes that the web server starts are part of the same job; the web server can control the lifetimes and resource usage of its children through the job APIs.
However, you could designate processes as being part of a specific job. A default job would be created when you log in; this job holds all the processes that the interactive user starts. When the web server daemon starts, it creates a job and adds itself to it. From then on, all processes that the web server starts are part of the same job; the web server can control the lifetimes and resource usage of its children through the job APIs.
-
mrd
Re:Process management - Getting Started
I haven't given these level of details much thought yet, which is why I started the thread.
I could have all processes operate with a given security context. The security context dictates resource privileges. Any processes spawned can at most inherit the rights of the creating process, although the creator can modify those rights of the child process during run-time.
I suppose removed rights would have to affect all descendants, and adding them would only return them to a descendant if its immediate parent provided them during creation or run-time update, with the exception of a special inheritance flag which gives the child the same privileges as the parent, or the same minus specific privileges.
For the process lifespan issue, I think jobs would make the most sense. How to securify the job APIs though is a question. I don't want any process to be able to make its lifespan independent of the session on a whim.
Perhaps, the process accessing the job API can only create jobs that exist within the job of the requesting process.
For daemons that last past the user session, the job for it would have to be spawned by some kind of system-level process, that's above user sessions.
Hmm
I could have all processes operate with a given security context. The security context dictates resource privileges. Any processes spawned can at most inherit the rights of the creating process, although the creator can modify those rights of the child process during run-time.
I suppose removed rights would have to affect all descendants, and adding them would only return them to a descendant if its immediate parent provided them during creation or run-time update, with the exception of a special inheritance flag which gives the child the same privileges as the parent, or the same minus specific privileges.
For the process lifespan issue, I think jobs would make the most sense. How to securify the job APIs though is a question. I don't want any process to be able to make its lifespan independent of the session on a whim.
Perhaps, the process accessing the job API can only create jobs that exist within the job of the requesting process.
For daemons that last past the user session, the job for it would have to be spawned by some kind of system-level process, that's above user sessions.
Hmm