Sorry to repeat a question that has been posed repeatedly, but i couldn't find a specific mention of memory issues. if a process terminates with _exit(0) or _Exit(0) can its memory block be lost to the OS?
Thanks,
-nuun
For just about any consumer O/S that will not happen. Modern multi-process Operating Systems will release any resources the process may have acquired (memory, locks, open files, etc) when the process shuts down. So I generally feel that memory or resource leaks "don't count" as leaks if I just acquire them at startup (not during runtime possibly repeatedly).
However, there are still lots of embedded/realtime platforms out there for which that is not true. If your program might be run on one of those, you should be scrupulous about freeing up acquired resources. But even there it is often easier to just reboot the device after each use...
Not on any decent modern O/S (Unix, Windows, whatever) - the O/S will reclaim the process's memory when the process dies, regardless of how cleanly it died.
In general, no. Operating systems handle that stuff for us.
Related
I recently learnt about user level threads and kernel level threads in Operating System book by tanenbaum. Since user level threads are handled by library packages and since had worked with node.js a bit, i concluded that node.js uses libuv for handling worker threads and hence uses user level threading.
But I wanted to know how node.js deals with the case when some worker thread makes a system call that is blocking and then the kernel will block the entire process even if some threads are capable of running.
But I wanted to know how node.js deals with the case when some worker thread makes a system call that is blocking and then the kernel will block the entire process even if some threads are capable of running.
This isn't what happens in a modern OS. Just because one thread in a process is reading/writing from the disk, the OS does NOT block the entire process from doing anything with its other threads.
Modern hardware uses DMA (Direct Memory Access) for reading/writing to disks precisely so that the CPU does not have to be blocked while a block of data is read from or written to a disk.
My question is related to knowledge on embedded Linux.
I just observed a strange reboot on my embedded project, which is very easy to reproduce.
When some condition is triggered, the system will like "freezing". I mean, its like encounter some infinite loop or be locked. Last for several seconds, system will quietly reboot. Not even core dump!!
I have no much clue about the cause. Generally will a lock or infinite loop can truly trigger Linux reboot? Or are there any things can freeze system and cause reboot with no core dump happens?
It is common on embedded systems to have a hardware watchdog; a timer implemented in hardware that resets the processor if it is allowed to expire.
Typically some software monitoring task continuously verifies the integrity of the system and restarts the hardware watchdog timer. If the monitoring task fails to run and the watchdog timer expires, the watchdog triggers a processor reset directly.
Your question is a bit hard to understand but yes, a "infinite loop" (the proper term is) in any application on any platform (including Linux) can crash a system. This happens obviously because an infinite loop can constantly take up memory and resources until there is none left. You mentioned you are doing embedded development (which can mean many different things) but usually means you are developing low-level applications built into Linux itself; these are more prone to crashing an OS than your average programming venture.
What is the CPU doing when there is only one process (like bash) and the process is waiting for user input?
It depends on the capability of the physical hardware. On typical PCs, the CPU would spend most of that time halted waiting for an interrupt to wake it up.
The CPU is (almost) never idle in a typical Linux system. If your bash process is halted waiting on input, the CPU will work on other processes until the blocking system call returns, signaling the bash process to resume.
There is a component in practically each and every one Operating System, being it the simplest bare-bone hardware Operating System or some more advanced one like FreeRTOS or some desktop or server Operating System which is usually called Scheduler.
Scheduler is responsible for planning and distributing CPU power and for eventually switching the CPU into low-power-consumption mode which in the extreme case may mean that the CPU goes totally offline and waits for the external hardware interrupt to wake it up.
By reading about schedulers and by reading their code available from open source Operating Systems you can find out "exactly" what does the CPU usually do.
Some starting points:
FreeRTOS - http://www.freertos.org/implementation/a00005.html
Linux - http://lxr.free-electrons.com/source/kernel/sched/fair.c
ReactOS - http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/thrdschd.c?revision=55247&view=markup
MenuetOS - http://www.menuetos.net/
OSDev.org, chapter "Scheduling" - http://wiki.osdev.org/Main_Page
Google: "linux scheduler source code"
I'm looking for a thread pool abstraction in Linux that provides the same level of kernel scheduler support that the Win32 thread pool provides. Specifically, I'm interested in finding a thread pool that maintains a certain number of running threads. When a running pool thread blocks on I/O, I want the thread pool to be smart enough to start another thread running.
Anyone know of anything like this for linux?
You really can't do this without OS support. There's no good way to tell that a thread is blocked on I/O. You wind up having to atomically increment a counter before each operation that might block and decrement it after. Then you need a thread to monitor that counter and create an additional thread if it's above zero. (Remove threads if they're idle more than a second or so.)
Generally speaking, it's not worth the effort. This only works so well on Windows because it's the "Windows way" and Windows is built from the ground up for it. For Linux, you should be using epoll or boost::asio. Use something that does things the "Linux way" rather than trying to make the Windows way work on non-Windows operating systems.
You can write your own wrappers that use IOCP on Windows, epoll on Linux, and so on. But these already exist, so you need not bother.
I have been working with an Windows application which reads from the 'nonpaged pool' to increase performance. In this case the nonpaged pool is the area of memory where the network drivers write data as they grab it off the wire.
How does Linux handle memory which network drivers (or other drivers) which require high speed exclusive access to RAM and does the question 'how do I read directly from nonpaged pool?' even make sense when applied to Linux?
Many thanks
related question
Some networks like Infiniband support RDMA, which requires being able to prevent paging for some of the pages in a process. See the mlock(), mlockall(), munlock(), munlockall() functions.
Other than that, I don't think there is a concept of "nonpaged pool", per se. Generally, kernel memory is AFAIK not pageable, but all user memory except that locked with mlock() or such is.