I am writing for generic linux/unix systems and have an unusual use case for which the design of the program is not clear to me.
(FYI: for those not familiar with the unix mentality, sometimes called the Unix Philosophy, the idea is to provide functionality by making lots of small programs that run independently, rather than making large conglomerate applications.)
So, in my case I want an application that will provide alerts. The application would be run from the command line with parameters defining the characteristics of the alert, then it would put itself into the background and wake up when the alert needs to be issued.
The problem is when a second alert is created. Rather than create a second process, I would like the application to notify the existing background process of the new alert and add it to its list of alerts. That way I have only a single "alert" process at any given time. One advantage of this is that since only one process controls all the alerts, it can list them. For example, the user might give a command like "alert list" and alert(2) will notify the existing alert process of the request and exit, then the existing process will print out all the alerts that are pending, then go into the background again.
What is the right way to do this?
I have concurent application (concurrent simulation of an airport) made with system v library (semaphores, message queue) and multiple processes.
I'm not allowed to use threads, that's why I have an processes thread and multiple 'planes' processes.
I would like to add some graphics to show traffic on an airport with GTK (with Cairo) library.
How to add graphic? When I tried to add it to airport process, gtk_main would block whole application. I thought about creating another process and add graphics to shared memory but I've read that it's not going to work.
What is the easiest/the best option?
Thank you very much!
It sounds like you should make a separate GUI process that the other processes can send messages to. One way to do this would be for your GUI process to export a DBus interface that the other processes can connect to. This way, when your GUI process receives a message from another process, your GTK main loop will emit a signal, and you can schedule a signal handler to deal with it and update the GUI accordingly.
I am using pthreads to create an multithreaded application (in this case a chat client - that mostly works, actually.)
The problem I have is that I have one thread trying to read and the other thread trying to print to the same console window.
For example if the user types in something to the console, but receives a message from the other thread, another, he could be looking at somethinganother - but when he presses enter the only data he submits is something!
Could anyone be so kind as to tell me how to deal with this?
I have a question regarding on how to design the following system:
My system is built of several clients listening to an environment. When a audio threshold is breached they send their information to a server, that has children listening on each connection. The server needs information from all the clients to make the necessary calculations.
Currently the server is working in UNIX and has forked out connections. They are working independently.
What I want to do is to tell the parent (in the server) that information has been sent and it's now time to process it. How should I do it?
I'm thinking of possible different ways to do it:
Using signal()in Unix to somehow tell the parent that something has happened
Convert to Threads and use some wait and notify functions
The signaling is preferable but I cannot figure out how to do it efficiently. Because the following can happen in my system:
If all the clients successfully sent information to their children of the server, how can I tell the parent that I'm ready in a efficient way? Don't know/I'm uncertain of how it will process them.
The server may not receive information from all clients. So the parent must wait for awhile for all the children but not too long. So I'm guessing some sort of timer?
Doen't use fork, and don't use signals. Use a thread pool.
What about a Unix Domain Socket for an inter-processes communication between children and father?
http://en.wikipedia.org/wiki/Unix_domain_socket
As soon as a child receives data through the TCP connection, the same data will be forwarded to the father process through the Unix Domain Socket and the latter process will be instantly notified
I am writing a simple instant messenger program in C on Linux.
Right now I have a program that binds a socket to a port on the local machine, and listens for text data being sent by another program that connected to my local machine IP and port.
Well, I can have this client send text data to my program, and have it displayed using stdout on my local machine; however, I cannot program a way to send data back to the client machine, because my program is busy listening and displaying the text sent by the client machine.
How would I go about either creating a new process (that listens and displays the text sent to it by the client machine, then takes that text and sends it to the other program's stdout, while the other program takes care of stdin being sent to the client machine) or create 2 programs that do the separate jobs (sending, receiving, and displaying), and sends the appropriate data to one another?
Sorry if that is weirdly worded, and I will clarify if need be. I looked into exec, execve, fork, etc. but am confused as to whether this is the appropriate path to look in to, or if there is a simpler way that I am missing.
Any help would be greatly appreciated, Thank you.
EDIT: In retrospect, I figured that this would be much easier accomplished with 2 separate programs. One, the IM server, and the others, the IM clients.
The IM Clients would connect to the IM server program, and send whatever text they wanted to the IM server. Then, the IM server would just record the data sent to it in a buffer/file with the names/ip's of the clients appended to the text sent to it by each client, and send that text (in format of name:text) to each client that is connected.
This would remove the need for complicated inter-process/program communication for stdin and stdout, and instead, use a simple client/server way of communicating, with the client programs displaying text sent to it from server via stdout, and using stdin to send whatever text to the server.
With this said, I am still interested in someone answering my original question: for science. Thank you all for reading, and hopefully someone will benefit from my mental brainstorming, or whatever answers come from the community.
however, i cannot program a way to send data back to the client machine, because my program is busy listening and displaying the text sent by the client machine.
The same socket that was returned from a listening-socket by accept() can be used for both sending and receiving data. So your socket is never "busy" just because you're reading from it ... you can write back on the same socket.
If you need to both read and write concurrently, then share the socket returned from accept() across two different threads. Since two different buffers are being used by the networking stack for sending and receiving on the socket, a dedicated thread for reading and another dedicated thread for writing to the socket will be thread-safe without the use of mutexes.
I would go with fork() - create a child process and now you have two different processes that can do two different things on two different sockets- one can receive and the other can send. I have no personal experience with coding a client/server like this yet, but that would be my first stab at solving your issue...
As #bdonlan mentioned in a comment, you definitely need a multiplexing call like select or preferably poll (or related syscalls like pselect, ppoll ...). These multiplexing calls are the primitive to wait on several channels at once (with pselect and ppoll able to atomically wait for both I/O events and signals). Read also the select tutorial man page. Of course, you can wait for several file descriptors, and you can wait for both reading & writing abilities (even on the same socket, if needed), in the same select or poll syscall.
All event-based loops and frameworks are using these multiplexing calls (like poll or select). You could also use libevent, or even (particularly when coding a graphical user interface application) some GUI toolkit like Gtk or Qt, which are all based around a central event loop.
I don't think that having a multi-process or multi-threaded application is useful in your case. You just need some event loop.
You might also ask to get a SIGIO signal when data arrives on your socket using fcntl with F_SETOWN, but this is not very useful for you. Then you often want to have your socket non-blocking.