Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have created 6 Sockets and simultaneously listening to all of them using select. I want to find out how much time does the CPU take switching from 1 socket to another. Does anyone know; if not can someone guide me please on how to compute this problem!
I think you may have misunderstood what the select call is actually doing, the man page for select says the following:
Three independent sets of file descriptors are watched. Those
listed in readfds will be watched to see if characters become
available for reading (more precisely, to see if a read will not
block; in particu- lar, a file descriptor is also ready on
end-of-file), those in writefds will be watched to see if a
write will not block, and those in exceptfds will be watched for
exceptions. On exit, the sets are modified in place to indicate
which file descriptors actually changed status. Each of the three
file descriptor sets may be specified as NULL if no file descriptors
are to be watched for the corresponding class of events.
So when your call to select returns what it will tell you is which, if any, of the file descriptors are (in your case) ready to be read from. It's then up to you to decide which to read and how to read it.
If you can I'd reccomend tracking down a copy of Unix Network Programming (by Stevens, Fenner, Rudoff). This will give you all the background information and example C code that you will ever want on network programming.
Or look at the tutorial here
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
I need to write a C program that launches another program with a modified priority, much as as the nice command does. In order to do that, I would like to find the PID of a process given as an argument (how can I do that?) and modify its priority level (how can I do that?).
Example: The command line might be ./a.out 5 sleep 500 &, and this should produce the same effect as nice -n 5 sleep 500&.
You are focusing on the wrong thing and therefore approaching the problem with the wrong idea. The key requirement is that your program must execute a specified command. Focusing on that will lead you toward how to achieve the process priority goal, at least by helping you frame the question more usefully. For example, you don't need to find any PID, because you don't need to adjust the niceness of an arbitrary process.
So how do you programmatically launch another command? The typical way would be to use one of the functions from the exec family. Since the program name and arguments are comming from the command line, execvp() is probably your best choice.
If you read their docs, you will find that the exec functions replace the process image in the current process. That is, they make the process in which they are called start and run a different program in place of the one it was running before. If the command you're going to launch will run in the current process, then it's the current process whose niceness you want to adjust, and for that there is nice().
You shouldn't need much more than those two functions and a little command-line parsing. Do read those functions' documentation carefully, however, especially execvp()'s, to make sure you set up the arguments correctly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have two different applications.I have to inform application_1 from application_2 that application_1 have to do some operation.(should call a function).
I can write some message 'take_action' in a text file from application_2 and application_1 will check that text file for 'take_action' on a regular interval.After getting 'take_action' it will call corresponding function and will write 'action_taken' to the text file.
I can use pipe or shared memory instead of file.
I can pass signal from application_2 through kill command (kill -SIGHUP) and call required function if SIGHUP signal comes to application_1.
Sample code for approach 1 and 3 are as follows.
approach_1:
in application_2:
fprintf(fp, "take_action");
in application_1:
int rd = read(filedReading, lineText, 13);
if (strcmp(lineText, "take_action") == 0)
{
reloadRule(); //calling required function
}
approach_3:
in application_2:
system("kill -SIGHUP");
in application_1:
void sig_handler(int signo)
{
switch(signo) {
case SIGUSR1:
opt_debug = opt_debug ? 0 : 1;
break;
case SIGHUP:
log_msg(LOG_NOTICE, "SIGHUP SIGNAL RECEIVED");
reloadRule(); //calling required function
default:
cleanexit(0);
}
Which approach is best for this kind of problem?
Opinion as always:
A temporary file is almost always the wrong thing to do if only 1 machine is involved, and RPC methods exist if you need multiple machines to cooperate.
When it is easy to establish the handle, anonymous pipes work well. You can use socketpair and mkfifo extend the pipe model to a wider set of scenarios.
Shared memory is the way forward when the pipe bandwidth is an issue. You can get a lot of data down a pipe, but it still involves a number of copies of the memory. Setting up a shared memory pool is a pain, but it gives both processes (almost) direct access to an agreed shared memory area, that is incredibly fast for data transfers. Of course you have to get this set up and there are potential synchronisation issues, but you can use your pipes to easily establish the connection or to synchronise the memory pool at a much lower bandwidth.
Signals are very limiting. You can only easily send a single flag, and they all already have reasons for existing, and what happens when "R" decides to use USR1 and USR2 for memory management, so you can't use your code with "R" programs, etc? Message queues extend signals to have a small payload, of course.
If you can use an anonymous pipe, then that's probably the best option.
This is because your ability to use a pipe means that your processes instances are intrinsically linked and started together, otherwise it would be hard to open a pipe between them.
If the processes are started together as a pair, they presumably intend to talk to exactly each other and not any other instances of the same programs, and they are probably expected to exit together. Pipes make this very simple, safe, and straight forward.
If the processes were started independently and you wanted to play matchmaker between various instances that weren't started strictly in pairs, then pipes would not have been an option, and sockets would have been a better fit.
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 6 years ago.
Improve this question
How can I determine if a command is successful or exists in C? This will need to be compatible with multiple architectures and routers (don't ask haha)
I was thinking of using popen or system or exec(v)(l). But the command I want to check for is sendmail. Since sendmail is a command that runs forever with no output this will be a little hard to do. Any ideas?
Thanks in advance.
If you know the path to sendmail, then as per the comments, use stat to check if it exists and is executable. If you know the search path then iterate through it and check each one.
If not - you could pass it /dev/null as stdin, in which case it will print an error message and exit. Then you can inspect the exit code from the process - for POSIX systems, the exit code will be 127 if the command could not be executed:
int rc = system("sendmail </dev/null 2>/dev/null");
if (WEXITSTATUS(rc)!=127) {
/* sendmail was found */
}
Of course this requires /dev/null to exist and shell redirects to be available.
I redirected stderr also, otherwise you will get error messages output from sendmail.
Just try to use it. If it's there, and you can execute it, it'll work. If it isn't, it won't and you can see why in errno.
The reason you don't try to check beforehand is twofold, and it's the same with files as with executables. First, you might get the check wrong. A lot of people will make the mistake of checking if a file exists and then wonder why opening it fails. They forgot to check if it's readable. There's no need to duplicate all these checks, just try to open it and see.
The second is it invites a race condition. For example, let's say you have two processes working on the same file. Time is moving down.
Process 1 Process 2
Check if file is readable.
It's readable!
Make the file unreadable.
Open that file.
File fails to open.
That's a very simple example, there are far, far worse consequences to a race condition. It illustrates that checking if a resource can be used and using that resource must be atomic: it has to happen in one single uninterruptible operation.
Avoid popen and system where you can. They run the command through the shell which invites security holes and unintended consequences of non-alphanumeric characters. Instead, use one of the exec[lv]p functions that will search the PATH for the executable without invoking a shell.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I know that socket() returns a handle (an integer one) for the communication instance, like a file descriptor.
I think that (to me at least) it would have made more sense if it returned an opaque pointer (like FILE* from fopen()), But an integer? How the implementation manages to work using this integer value to differentiate between a communication instance and the other?
(Same thing applies to open() I think?)
How the implementation manages to work using this integer value to differentiate between a communication instance and the other?
The details depend on the implementation, but it's safe to assume that the operating system maps the file handle to the appropriate chunk of data. Exactly what the integer means doesn't matter -- it could be an index into an array, a number chosen at random and used as an identifier, or something else. All that matters in your code is that the number represents a specific file or socket.
The integer that's returned by socket() is a file descriptor, i.e. a value that refers to a specific FILE data structure. It's often said of Unix that "everything is a file" because the file system is used as an interface to many resources including disk-based files, pipes, devices like printers and terminals, and network connections. Functions that create new file handles, such as open(), accept(), pipe(), and socket(), are expected to return the associated file descriptor.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I have some doubts about pipes appreciate help if anyone knows
A pipe can be shared by multiple processes simultaneously allowing these processes exchanging "messages" to each other.
When there are multiple read processes of the same pipe can all read the same message (sent only once and not multiple copies)?
In a multi-threaded environment it is possible that a message sent by a process is corrupted when writing to the pipe?
thanks for listening
Stop thinking about "messages". The pipe accepts a sequence of bytes, and your application is entirely responsible for assigning any structure to the sequence. Each byte written to the pipe can be read exactly once, and not multiple times. If each write to the pipe is a fixed size and smaller than a system specified amount, then the write will be atomic and the data will not be "corrupted" (interleaved with other writes) during the write. However, if any of the readers are reading blocks of a different size, then data may be interleaved on the read end. (eg, a writer writes 64 bytes as one "message", but a reader reads 60 bytes from the pipe. The reader expecting a 64 byte sequence will then get 4 bytes from the tail of one and 60 from the start of another, and your data may appear "corrupted"). It is very easy to get "corrupted" data in a multi-threaded environment. It is possible to ensure that none of the writes are interleaved, but it can be difficult to get it right. Keep the messages small and of a fixed size, and make sure the are written with a single write system call (eg, do not use fprintf on a FILE* with the pipe as the underlying file descriptor.)
Note that I'm using the word "corrupted" in quotes throughout, because I believe you really mean interleaved. The byte sequence that you write will not be corrupt from the system's perspective. You may not get back what you expect, but that is not corruption of the data. Rather, it is a programming error.