I have two questions:
Is there any API in Qt for getting all the processes that are running right now?
Given the name of a process, can I check if there is such a process currently running?
Process APIs are notoriously platform-dependent. Qt provides just the bare minimum for spawning new processes with QProcess. Interacting with any processes on the system (that you didn't start) is out of its depth.
It's also beyond the reach of things like Boost.Process. Well, at least for now. Note their comment:
Boost.Process' long-term goal is to provide a portable abstraction layer over the operating system that allows the programmer to manage any running process, not only those spawned by it. Due to the complexity in offering such an interface, the library currently focuses on child process management alone.
I'm unaware of any good C++ library for cross-platform arbitrary process listing and management. You kind of have to just pick the platforms you want to support and call their APIs. (Or call out to an external utility of some kind that will give you back the info you need.)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Unix Operating System Picture
The picture provided is a sketh of a Unix operating system.
I'm not sure how the Unix OS works and these are some questions I had about it.
What is the overall functionalitiy of each of the layers labeled by numbers and the interfaces between the adjacent layers?
What is the purpose of organizing the components like this?
How would each of these layers differ from the OS of an android or IOS (mobile OS)
Thanks!
Userspace
The two top layer (the one called "the users"), plus the one labeled (1), are the userspace.
A UNIX process can't exist outside userspace.
Layer (1) is sometimes refered as "shell" layer.
It's not always clear what is or is not is shell layer. For short, we can consider this as the "system" part of userspace (by opposition to end-user applications). Typically, think of the command line utilities like cp, rm, mv, ln, ls, etc.
userspace provides memory isolation between process (one process can't write unexpectedly in other processes memory space).
Also, a program in userspace runs under a user identity, which provides him permissions to manipulate some resources in the system. An exemple is : you have a file that you owns in your home directory, which permission are -r-------- (readonly, only for the owner).
No other (unpriviledged) user in the system will be able to display its content, since any command they run inherit their identity and permissions.
Kernel
The layer 2 is the kernel. It is a very priviledged piece of code that is responsible to provide the features needed to acheive the userspace.
It is also the first piece of the system that is loaded into memory and then executed at boot time (just after the firmware bootloader).
It initialise the CPU and motherboard devices, and notably sets up the Memory Management Unit of modern processor. Momery isolation of processes relies on MMU operation mode.
The kernel is responsible to manage resources allocation (memory, files on hard disk, etc). Also responsible to kill a process that makes illegal accesses (for instance, outside its allocated memory space).
Why two layer ?
Beyond the technical justification presented above, there is another strong reason to have make this choice.
This layer concept comes from the early UNIX systems, and it is a core concept of all modern OSes (NB : the term Operating System, sometimes refers to the kernel only).
Indeed, by the time, they was no way to port a software to another computer model, furthermore if not designed by the same manufacturer.
The kernel was introduced to ease the port of software : when receiving a new computer model, Bell Labs had to make the effort to port the kernel, and the C compiler to this new machine, maybe some tweaks in system libraries.
But when this port was acheived, all other userspace software could be recompiled and executed on the new machine.
Also, it allows a same C code to be used (theorically) on different kernel implementation.
For instance, many of the tools you can find under linux are also usable under FreeBSD.
I don't mean a clone of the tools, i mean the same source code, compiled for the right target system.
Those comment are cleary not exhaustive, it's a hugely vast topic, but I hope it helps for pathfinding :)
Concrete instance :
basically GNU is a collection of system tools (a shell)
in a GNU/ Linux system GNU runs on a Linux kernel
NB : paradoxally, GNU is older than Linux
EDIT
I don't know for iOS but android is, basically a Linux system.
So it implements this layer concept, with a kernel and a userspace.
Anyway, despite it is based on Linux kernel, not on "vanilla" version, but a version highly tweaked by google developers.
The shell is also highly specific for the base distribution form google (AOSP) but theorically, GNU tools can be installed.
I am linking against a library that is built with OpenMPI support for internal processes.
My application is being built with no MPI support, and I link against this library. I have no idea what is happening behind the hood with regards to mpi. If library A loads/calls functions from openmpi, does this mean I can run my application with runmpi to get the library processes to distribute themselves? If I decide to make the application MPI aware and want to use mpich2 instead of OpenMPI or if I want to use Library B that is linked against mpich instead of openmpi, will the library and my application behave themselves in their individual message spaces? Is it typical to force application developers to explicitly link an mpi implementation to use an mpi-enabled library?
The normal practice is that the developer ultimately compiles and links everything against a single MPI implementation. Where there are libraries depending on MPI, I typically see builds of the library for each available MPI implementation on a system. If you could somehow manage to link in two MPI implementations, and come up with their separate MPI_Init and MPI_COMM_WORLD definitions to use in the separate pieces of code, it might even work. That would be really tenuous, though. Don't do it.
As for your earlier question, it is almost possible to have an application call into a library using MPI and just have it do the right thing. First, the code will have to call MPI_Init somewhere. whether that's in the client or wholly encapsulated in the library may vary. The library will have to know what MPI communicator it's supposed to use; typically the client code would pass one in. Finally, the client code will have to take account of the fact that it will run on all MPI processes, not just one of them. So if it does any IO or other computation that should only happen in one process, then you'll need to set conditions accordingly.
Disclaimer: I'm a c# ASP.NET developer learning "RoR". Sorry if this question doesn't "get" RoR, any corrections greatly appreciated!
What is multithreading
My understanding of "multithread" ability in web apps is twofold:
Every time a web/app server receives a request it can assign a thread to the new request, thus multiple requests can run concurrently.
The app runtime + language allows for multiple threads to be used WITHIN a single request (in ASP.NET via "Async" methods and keywords for example).
In this way, IIS7 + ASP.NET can do points 1 AND 2.
I'm confused about RoR
I've read these two articles and they have left me confused:
Clearing up some things about LinkedIn mobile’s move from Rails to
node.js
How to deploy a multi-threaded Rails app
question one.
I think I understand that RoR doesn't lend itself very well to point number 2 above, that is, having multiple threads within the same request, have I got that right?
question two.
Just to be crystal clear, RoR app/web servers can also do point number 1 above right (that is, multiple requests can run concurrently)? is that not always the case with RoR?
Question 1:
You can spawn more Ruby threads in one request if you want, although that seems to be outside the typical use case for Rails. There are uses for it for certain long-running IO or external operations.
Question 2:
The limiting factor for Ruby concurrency in general, not just with Rails, is the Global Interpreter Lock. This feature of Ruby prevents more than 1 thread of Ruby from executing at any given time per process. The lock is released whenever there is non-Ruby code executing, such as waiting for disk IO or SQL responses. You can get around this by using a different implementation of Ruby than the default, such as JRuby, but not all.
Phusion Passenger uses process based concurrency to handle a few requests concurrently, so, strictly speaking, is not "multithreaded," but is still concurrent.
This talk from Ruby MidWest 2011 has some good thoughts on getting multithreaded Ruby on Rails going.
Since this is about "from ASP.NET to RoR" there is another small but important detail to remember: In *nix environments it's common to achieve concurrency of a service application through multi-processing rather than multi-threading. This is an architecture that goes way back and is related to the relatively cheap cost of multi-processing on *nix systems using fork and Copy-on-Write. Each process serves one request at a time in a single thread and the main process controls spawning and killing worker child processes. Multiple requests are served concurrently by different child processes.
Modern service applications, for example Apache, have multi-process, multi-threaded, and even combined modes (where the service forks several processes, each running several threads).
In cases where the application was built with portability at mind (examples again: Apache, MySQL, etc) it is customary to run it in multi-process or combined mode on *nix systems, and in multi-threaded mode on Windows servers.
However, admittedly Rails is somewhat lacking on the Windows front. It's not that you can't run it on Windows, it's just that not a lot of effort went into making sure it runs well and smoothly for production use on Windows servers. It's not a common production platform among the RoR community.
As a result, Eventhough Rails itself is thread-safe since version 2.2, there isn't yet a good multi-threaded server for it on Windows servers. And you get the best results by running it on *nix servers using multi-process/single-threaded concurrency model.
Rails as a framework is thread-safe. So, the answer is yes!
The second link that you posted here names many of the Rails servers that don't do well with multi-threading. He later mentions that nginx is the way to go (it is definitely the most popular one and highly recommended). But he doesn't mention what made him come up to the conclusions.
Ruby 1.9.3 came out recently and has some new threading goodness built in which didn't exist before.
Use of multi-threading generally depends on the use case.
Personally I have tried it once an year ago and it had worked but I haven't used it in any production code because I haven't come across a use case where using multi-threading made more sense over pushing the long running task to a background job.
I would love to explore this more. So, if you can describe what you are trying to achieve then maybe we can do a POC.
I want to use Asio and Qt together ? each of them have a two method that must be called and each of them are blocking for example : Asio has io_service.run() and qt has QCoreApplication.exec() if I run one of them then another cannot be run.
I have two solutions:
create another thread and call io_service.run() from that.
create a timer with 100ms cycle and call io_service.poll() from same thread that call QCoreApplication.exec().
These solutions are correct?
This is simple solution and works on every platform, but it has some minor drawback. You are introducing latency to asio-part of your application, which may be acceptable or not - depends on your case.
You may be interested in my solution, that makes real integration of asio and QT mainloops.
Look also at the following question for more on this topic: How to integrate Boost.Asio main loop in GUI framework like Qt4 or GTK
You definitely want to look into multi-threading your application. Qt helps you out with pretty good platform-independent threading classes. You'll also need to address communication between objects owned by different threads and also will need to bear in mind that painting is limited outside of the GUI thread.
The article Porting Qt for Embedded Linux to Another Operating System lists five things you have to do to port Qt for Embedded Linux to another OS. From the article:
There are several issues to be aware of if you plan to do your own port to another operating system. In particular you must resolve Qt for Embedded Linux's shared memory and semaphores (used to share window regions), and you must provide something similar to Unix-domain sockets for inter-application communication. You must also provide a screen driver, and if you want to implement sound you must provide your own sound server. Finally you must modify the event dispatcher used by Qt for Embedded Linux.
Is it really this easy to port Qt to another OS, or have i missed some information?
Another important component to port would be QAtomic, to ensure that you can have atomic operations and implicit sharing working well. See also
http://labs.trolltech.com/blogs/2007/08/28/say-hello-to-qatomicint-and-qatomicpointer/
Since Qt has been ported a large number of times it seems logical that it would be inherently simple. However the issue really is on the platform you are porting to and how many features it currently supports.
Assuming you find all those things easy, then the port is easy.
After investigating this in more detail I have come to the conclusion that the article "Porting Qt for Embedded Linux to Another Operating System" assumes that you are porting Qt to a very "linux-like" OS.
I have attempted this and currently making progress.
Some difficulties:
IDE - I have to manually add all Qt files and fight the compiler with #ifdefs until it builds with all dependencies in place.
Linux(ness) - I've had to disable all Linux/Windows things that are not supported in my target OS: threads, sockets, processes. Even the timers are slightly different.
Tips:
Start small : I compiled QtCore as a standard lib within my IDE, next up is QtGui which is a behemoth compared to QtCore.
I plan to run only a single QThread, so I have to artificially made a Thread object to avoid null pointers. You cannot compile out Thread information as it is key to all QObjects.
So far I have an qeventloop running within a qcoreapplication.
I wrote some inline assembly but had serious difficulties with my IDE and compilation. I left it in C++ and let the assembler handle it for me. Because I am single-threaded, I am not too concerned with shared data/ exclusive access as required by the atomic operations.