In linux kernel, we can use current->comm to get the name of the process currently running. Could this be a thread under a normal process? Linux has this light-weight process concept, which means thread is also a process.
To access group leader information of a thread you can use "current->group_leader". In Linux, threads are just another process but shares "memory" group_leader.
Pthread function calls "clone" system call with CLONE_VM.
Yes. Generally comm will be the same for all threads in a process, but it is possible to change it for a thread using prctl(PR_SET_NAME, ...).
Related
I've recently started learning VB.NET and I'm wondering is there an easy way of killing off all processes a VB.NET application uses, for example I've created a form which pings a given IP address, this application creates a process cmd.exe and sends the ping argument, this in turn creates following processes:
cmd.exe
conhost.exe
ping.exe
If I Kill () the main process it kills off cmd.exe but not conhost.exe nor ping.exe, do I need to manually kill these also? By killing off the main process will it not automatically kill off associated processes? If that makes sense. Another thing I don't understand, I tried using Close () but nothing appears to happen, all processes keep on running. I want to be able for a user to close the form and for all associate processes to be closed/killed.
It is much better to use the System.Net.NetworkInformation.Ping class to perform a ping (as Hans Passant mentioned).
In general, if you use proc = System.Diagnostics.Process.Start(...), you should be able to kill the process and its child processes with proc.kill. However, it is possible for a process to launch other processes that will not be immediately terminated with kill. It would be a bad idea to terminate leftover processes manually, for a number of reasons.
When using NSThread's detachNewThreadSelector:toTarget:withObject:, I'm finding that the thread will fully complete its execution before the application is terminated normally if the user were to attempt to quit the application while the background process was executing.
In this case, this is the behavior I desire, but I couldn't find anything in Apple's docs that suggests that this will always be the case. The only relevant information I was able to find was the following, from Apple's Threading Programming Guide:
Important: At application exit time, detached threads can be terminated immediately but joinable threads cannot. Each joinable thread must be joined before the process is allowed to exit. Joinable threads may therefore be preferable in cases where the thread is doing critical work that should not be interrupted, such as saving data to disk.
So from this, I know that detached threads can be terminated at the time of application exit, but will they ever be terminated automatically? Or, am I always safe to assume the thread will complete its execution before the application quits?
You cannot assume that any thread -- including the main thread -- will ever complete execution normally, regardless of the documentation.
This is because the user can quit an application at any time, the system may lose power/panic, or the app may crash.
As for detached threads, it would not be unheard of for the system frameworks to automatically terminate the app forcibly after some timeout once the main event loop has given up the ghost.
Is do_fork() safe from preemption? In other words, can the parent process allocate a new task struct and then get preempted, before getting a chance to insert the new task struct into the ready queue?
It's not safe from preemption.
The do_fork calls copy_process which in turn does the sched_fork that initializes the task. Afterwards the do_fork calls wake_up_new_task in order to put it on the run queue.
This is separated in order to be able to kill or terminate a process before being scheduled.
The sched_fork disables preemption, but enables it once its done with its work, making it possible for the kernel to preempt before calling the wake_up_new_task and putting it on the run queue.
This is based on my knowledge of the 2.6 kernel.
after reading and searching about OS and process and threads, I checked on wiki and it said,
A computer program is a passive
collection of instructions, a process
is the actual execution of those
instructions. Several processes may be
associated with the same program; for
example, opening up several instances
of the same program often means more
than one process is being executed.
Now is it possible for a program to have more than one process and I am not including the possibility of running more than one instance of the same program. I mean one instance of one program is running, is it possible for a program to have more than one process?
If yes, how? If no, why not?
I am a newbie in this, but damn curious :)
Thanks for all your help..
Yes, fairly obviously - you can run two or more copies of most programs - I routinely have about 5 copies of vim running, and each of those is a separate process. As to how, the OS loads the executable file, creates a process and then tells that process to start executing the file contents.
It is most definitely possible but a desktop application might not be a good example and I think this is the source of your confusion.
Consider a webserver instead (NginX or Apache). There is one master process and multiple worker processes at work. The master process "accpets" the work , so to speak, and delegates it to the workers. Both NginX and Apache could be configured to any number of worker processes.
At our company we are in the business of delivering a SaaS that helps businesses have an online chat with their visitors via their websites. The back-end part of our system has multiple "service"es communicating with each other to accomplish the task. Each service has multiple instances running.
I want to write a program, that should be notified by O.S. whenever any running process on that OS dies.
I don't want to myself poll and compare everytime if a previously existing process has died. I want my program to be alerted by OS whenever a process termination happens.
How do I go about it? Some sample code would be very helpful.
PS: Looking for approaches in Java/C++.
Sounds like you want PsSetCreateProcessNotifyRoutine(). See this article to get started:
http://www.codeproject.com/KB/threads/procmon.aspx
Under Unix, you could use the sigchld signal to get notified of the death of the process. This requires, however, that the process being monitored is a child process of the monitoring process.
Under Windows, you might need to have a valid handle to the process. If you spawn the process yourself using CreateProcess, you get the handle for free, otherwise you must acquire by other means. It might then be possible to wait for the process to terminate by calling WaitForSingleObject on the handle.
Sorry, I don't have any example code for this. I am not even sure, that waiting on the process handle under Windows really awaits termination of the process (as opposed to some other "significant" condition, which causes the process handle to enter "signalled" state or something).
I don't have a code sample ready but one idea – on Linux – might be to find out the ID of the process you'd like to watch when first starting your watcher program (e.g. using $ pgrep) and then using inotify to watch /proc/<PID>/ – which gets deleted when the process dies. In contrast to polling, this doesn't cost any significant CPU resources.
Now, procfs is not completely supported by inotify, so I can't guarantee this approach would actually work but it is certainly worth looking into.