I an new at working with IPC objects with synchronization purposes for processes and threads.
Is there any special way to implement a Monitor in C? (such as semaphores, pipes, sockets, etc.) Is there a special .h file that has a specific object to use here?
If not, which is the best way to implement this?
Thanks in advance!
Silvio.
I'd use select, it works pretty much for everything you need: http://linux.die.net/man/2/select
Beyond that, I usually use the pthread style functions for mutexes/semaphores, but it's really down to what the task at hand actually is.
Best way would be a separate process. When a process starts it registers this fact to the monitor process. Then the monitor process can use calls to check if the process that registered with it is still running
Depends on what your scenario but my guess is you want something that requires very little setup to implement is which case I'd go with septical.
Related
I have one confusion relating to IOCP (among so many others) as I am fairly new to multi-threaded programming. Can we not use IOCP without having to associate them with a device like a file/port/namedpipe etc.?
What I really want to do is to build a library that implements a Thread pool which caters to Queues with different priorities. Anyone using my library should be able to pass any function and any parameters - these may not just be reads and writes of IOs. IOCP seems to be the best for efficient management of a threadpool except that I need to associate a device with it. What if I am not working with files or communication over network? Maybe I just need different clients to perform different functions using thread pool, perhaps on the same machine? How can I workaround that?
Any hints, ideas, pointers will be much appreciated. Thanks for your help in advance, and kindly excuse my ignorance on this topic.
I have a server that spawns a new process or thread for every incoming request and I need to read and write a variable defined in this server from both threads and processes. Since the server program needs to work both on UNIX and Windows I need to share the variable in a portable way, but how do I do it?
I need to use the standard C library or the native syscalls, so please don’t suggest third party libraries.
shared memory is operating system specific. On Linux, consider reading shm_overview(7) and (since with shared memory you always need some way to synchronize) sem_overview(7).
Of course you need to find out the similar (but probably not equivalent) Windows function calls.
Notice that threads are not the same as processes. Threads by definition share a common single address space. With threads, the main issue is then mostly synchronization, often using mutexes (e.g. pthread_mutex_lock etc...). On Linux, read a pthread tutorial & pthreads(7)
Recall that several libraries (glib, QtCore, Poco, ...) provide useful abstractions above operating system specific functionalities, but you seem to want avoiding them.
At last, I am not at all sure that sharing a variable like you ask is the best way to achieve your goals (I would definitely consider some message passing approach with an event loop: pipe(7) & poll(2), perhaps with a textual protocol à la JSON).
I've got a general question about daemons in C, that I haven't seen an answer to by now.
Is there a way how one should implement the control of a daemon process, like a convention or standard?
--Rest is further explanation--
I have seen multiple documents teaching the basics how to create a daemon in C. Forking, closing file descriptors, changing root, etc... no problem. And they all stop, when the process enters a endless loop (when the daemon process is created - so to say). But this is only half the way when it comes to coding a daemon; you have to control it somehow. I can make it work different ways, but I have the feeling there is a lot more to it.
For this (checking if there is a process already running or for stopping a running daemon process, or ...) I have seen different approaches (UNIX sockets, file locks, pid-files, ...) with their pros and cons. But it seemed to me like opinions or personal flavors; "why don't you just...?" or "I've done it this way, it worked for me". And I am not sure if this is a sign of freedom or not.
I mean, if you take a look at sshd, httpd, syslogd, etc... they all can be controlled via init-scripts or the service command (start|stop|status). This looks like a standard. But is this just some loose convention a lot of people try to follow or is there some kind of "framework" in the deep sea of C functions? Do you have to make it work somehow - for example make your program respond to a "stop" argument and end the daemon process somehow? Or is there some kind of standard, convention, a UNIX-way, best practices... that one should follow to write "good, clean code" and that integrates well in most environments?
My main question comes down to: Is there a way it's meant to be done?
And if so, where could I find more information? I guess there is more to take care of, than just starting and stopping.
There is no standard, but there is a de facto standard, as you have already noticed.
I suggest you take one of those examples, such as Apache, and look into what apachectl does. You'll find it sends signals to the daemon, based on knowing the PID, which it reads from a file.
In the case of Apache, signals make sense, because you don't want some kind of HTTP request to be able to stop the server. In the case of a DBMS, you might want to respond to incoming commands to stop the server, provided you authenticate and authorize first.
You can use signals, or the daemon could create a unix socket (with appropriate permissions) and listen for data on in. It depends on how much control you need to implement over your program.
Remember that for low-traffic things, it can be convenient to use xinetd and let it fork and handle the connection, and just respond to the request.
I am trying to create two applications. One application should take inputs from user like name, address, phone number and send that information to the other application to store it. This should also be capable of reading the stored address information from the other application.
My assumptions for this:
I am planning to use system() process in application1 to create application2.
For communication between these processes, shared memory as IPC.
Can anyone suggest me whether this is the correct way for this task or is there any best and easy approach for this task.
Thank you.
You could take a look at google protocol buffers if you are looking for communication between processes in python , java or c++.
It is clean and elegant and works across files and sockets.
You can communicate using sockets between the two processes.
I am using C language and Linux as my programming platform.
I am developing a user-space application that runs in a background, like a daemon. And my problem is, I want another user-space application to communicate with this daemon.
I know that I have to use Interprocess Communication method but I don't know what is the correct implementation.
But using IPC in my communication implementation is my other option. Actually I just want to change the attribute of my daemon by using another application. Please see below a senario:
My daemon runs in a background.
Then some application will control the properties of a daemon, like sleeping delay time.
My first option is by accessing a file with the values of the properties. So that my deamon will poll that values. While the other application will change that values.
I am not sure the efficiency of my options. Please advice.
THanks.
Updating the config file and sending a signal to cause re-read is a standard practise, cheap and easy.
You're looking for D-Bus. Store the initial values in a file, then listen over D-Bus for requests to change it.
Unix domain sockets are a simple IPC method.
If I were you, I'd forego IPC completely and instead have the daemon monitor a config file for changes. IPC is only really needed if you're going to be sending thousands of messages per second and the overhead would get intolerable.
inotify is an option for file monitoring.
I'd make the daemon listen on a pipe/fifo if it's simple enough that you only need to read a couple of bytes fed in from another program. Otherwise a local domain socket is nice to run a simple protocol over.