I want my code to be able to handle the error cases, such as unsuccessful return of functions. For instance,pthread_create,normally I use the function herebelow:
int thread_check1;
pthread_t function;
thread_check1 = pthread_create( &function, NULL, function_function, NULL);
if(thread_check1 != 0){
fprintf(stderr, "pthread_create error\n");
exit(1);
}
Considering the error cases, would it be correct to call the same function till it returns 0(for this specific function) as it is done below?
thread_check1 = pthread_create( &function, NULL, function_function, NULL);
while(thread_check1 != 0){
thread_check1 = pthread_create( &function, NULL, function_function, NULL);
}
Can I apply the same logic to the other C functions that returns a value? Otherwise, how would you suggest to handle error cases (for the function returns) without exiting from the program?
You could do that, but more properly. Assume there is function f which has different return values. You can do as follows:
tries_left = 1000;
do
{
ret = f(params);
if (ret == OK)
break;
else if (ret == SOMETHING_UNRECOVERABLE)
/* break with failure */
else if (ret == SOMETHING_FIXABLE)
/* fix params */
else
/* sleep a little */
} while (--tries_left);
There are many things to consider here:
Avoid infinite loop. If there is something inherently wrong, you wouldn't want to get stuck in a loop. So after some tries, you would want to break and fail. This is where tries_left comes into play.
Fail if unrecoverable. If the error tells you that the problem is not fixable, stop trying. For example if you are trying to mount a drive and it tells you /dev/sda6 doesn't exist, there is no point in retrying.
Try actually handling the problem. In some cases, you may be able to try different parameters. For example if you are trying to create a backup file and you can't, you can try changing the directory or name of the file and try again.
Don't use 100% CPU. If you want to retry, at least give some breathing room in between tries for whatever problem there was to go away, or in the very least to avoid using maximum CPU.
In the end, to avoid repeating yourself if you have different functions that need to be handled like this, you could put this whole thing in a macro and call it like CHECK_AND_RETRY(f(params));, assuming it is possible to understand what return value is unrecoverable and what is fixable no matter the function (kind of restrict, but there is no beautiful solution).
As Joe already mentions it heavily depends on your requirements and on the method you want to use. Whenever something fails there's usually a reason. For example no more memory is available if malloc returns zero.
Trying to get new memory without actually using free under such circumstances will usually result in an infinite loop, so that's something you shouldn't do. On the other hand, when you want to open a file but it's currently blocked by another process you could do something similar.
However, keep in mind that such a loop will usually keep the CPU busy and slow down other processes/threads. Also you could use a thing between your current solutions and try several times before you exit:
error_count = 0;
thread_check1 = pthread_create( &function, NULL, function_function, NULL);
while(thread_check1 != 0){
sleep(1); // wait some time before we try again
if(++error_count == 10){
fprintf(stderr, "Could not create thread\n");
return 1;
}
thread_check1 = pthread_create( &function, NULL, function_function, NULL);
}
What should be done in case of failure depends solely on your requirements.
Usually it will depend on type of the error (fatal, acceptable etc.) and it's impact on the program.
Getting back to your example, failure to create thread should probably be treated as fatal error since the issue that prevented it's creation will most likely not go away on second or third attempt (again, it depends on your requirements and environment) thus not looping is probably a better approach here. Yet again, whether you want to quit the program or not in case of failure is up to you - can your program continue running without this thread? If yes, terminating the program isn't necessary. Otherwise - terminate.
I would definitely not recommend handling errors like that. In the case there is a genuine problem you will be stuck in an infinite loop. An example is opening a file when it is already in use. I would say you should do one of the following:
Print/Log the error and stop execution.
Allow certain errors (Add a && to the if), this example would retry only if the error code is 3
if (thread_check1 != 0) {
If (thread_check1 == 3) retry;
Related
I am studying how to write a shell in C, and I have come across a method to use a "busy loop around the sleep function when implementing wait command". In the loop, the while(1) loop is used. I suppose to loop unconditionally, and hence take up some processing time and space? What exactly is the purpose of a busy loop? Also, if the only objective in a lazy loop is to have an unconditional loop, then can't we use any other form of loop like for(;;) instead of while(1) too?
A busy loop is a loop which purposely wastes time waiting for something to happen. Normally, you would want to avoid busy loops at all costs, as they consume CPU time doing nothing and therefore are a waste of resources, but there are rare cases in which they might be needed.
One of those cases is indeed when you need to sleep for a long amount of time and you have things like signal handlers installed that could interrupt sleeping. However, a "sleep busy loop" is hardly a busy loop at all, since almost all the time is spent sleeping.
You can build a busy loop with any loop construct you prefer, after all for, while, do ... while and goto are all interchangeable constructs in C given the appropriate control code.
Here's an example using clock_nanosleep:
// I want to sleep for 10 seconds, but I cannot do it just with a single
// syscall as it might get interrupted, I need to continue requesting to
// sleep untill the entire 10 seconds have elapsed.
struct timespec requested = { .tv_sec = 10, .tv_nsec = 0 };
struct timespec remaining;
int err;
for (;;) {
err = clock_nanosleep(CLOCK_MONOTONIC, 0, &requested, &remaining);
if (err == 0) {
// We're done sleeping
break;
}
if (err != EINTR) {
// Some error occurred, check the value of err
// Handle err somehow
break;
}
// err == EINTR, we did not finish sleeping all the requested time
// Just keep going...
requested = remaining;
}
An actual busy loop would look something like the following, where var is supposedly some sort of atomic variable set by somebody else (e.g. another thread):
while (var != 1);
// or equivalent
while (1) {
if (var == 1)
break;
}
Needless to say, this is the kind of loop that you want to avoid as it is continuously checking for a condition wasting CPU. A better implementation would be to use signals, pthread condition variables, semaphores, etc. There are usually plenty of different ways to avoid busy looping.
Finally, note that in the above case, as #einpoklum says in the comments, the compiler may "optimize" the entire loop body away by dropping the check for var, unless it has some idea that it might change. A volatile qualifier can help, but it really depends on the scenario, don't take the above code as anything other than a silly example.
I used timer_create() in the following code. It will trigger the handler only once after 10 seconds.
struct itimerspec itimer = { { 0, 0 }, { 10, 0 } };
struct sigevent si;
memset (&si, 0, sizeof (struct sigevent));
si.sigev_notify = SIGEV_THREAD;
si.sigev_notify_attributes = NULL;
si.sigev_notify_function = t;
if (timer_create (CLOCK_REALTIME, &si, &timer) < 0)
{
fprintf (stderr, "[%d]: %s\n", __LINE__, strerror (errno));
exit (errno);
}
if (timer_settime (timer, 0, &itimer, NULL) < 0)
{
fprintf (stderr, "[%d]: %s\n", __LINE__, strerror (errno));
exit (errno);
}
My question is, after 10 seconds my handler got triggered - now do I have to delete the timer using timer_delete() before exiting the process? Or, since it is triggered only once, is there no need to delete it explicitly?
Yes, you need to explicitly delete the timer.
Take a look at the man(2) page for timer_create. In the notes section (the third note, specifically), you'll see that every call to timer_create uses resources in the kernel, and the total number of timers, across all processes, that can be allocated by the kernel at once is limited.
If you don't delete your timers, you will eventually run out of them and any applications that need to allocate timers may fail.
It's just like memory leaks - clean up the resources you use, or you'll eventually run out.
Reply to your follow-up question
In the comments below, you asked if it is okay to call timer_delete from inside your callback function. I was unsure of how to respond, so I opened question about it myself. The answer seems to be maybe. You can try to experiment with it and see if it works, but I would recommend against it. I've never seen any code that deletes the timer from within the callback, and the idea of deallocating the timer resources before an event has finished being handled makes me nervous.
Also, testing it may yield okay results sometimes, but have random failures since you're dealing with asynchronous events. Furthermore, your main program needs to be running until the callback completes anyway (they run in the same process, just different threads), so you may as well delete the timer in your main thread right before exiting. I think it's the safer solution, and will be easier to debug.
Pretty much as the title says. I have a snippet of code that looks like this:
pid_t = p;
p = fork();
if (p == 0) {
childfn();
} else if (p > 0) {
parentfn();
} else {
// error
}
I want to ensure that either the parent or the child executes (but not returns from) their respective functions before the other.
Something like a call to sleep() would probably work, but is not guaranteed by any standard, and would just be exploiting an implementation detail of the OS's scheduler...is this possible? Would vfork work?
edit: Both of the functions find their way down to a system() call, one of which will not return until the other is started. So to re-iterate: I need to ensure that either the parent or the child only calls their respective functions (but not returns, cause they won't, which is what all of the mutex based solutions below offer) before the other. Any ideas? Sorry for the lack of clarity.
edit2: Having one process call sched_yield and sleep, I seem to be getting pretty reliable results. vfork does provide the semantics I am looking for, but comes with too many restrictions on what I can do in the child process (I can pretty much only call exec). So, I have found some work-arounds that are good enough, but no real solution. vfork is probably the closest thing to what I was looking for, but all the solutions presented below would work more or less.
This problem would normally be solved by a mutex or a semaphore. For example:
// Get a page of shared memory
int pagesize = getpagesize();
void *mem = mmap(NULL, pagesize, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0);
if(!mem)
{
perror("mmap");
return 1;
}
// Put the semaphore at the start of the shared page. The rest of the page
// is unused.
sem_t *sem = mem;
sem_init(sem, 1, 1);
pid_t p = fork();
if (p == 0) {
sem_wait(sem);
childfn();
sem_post(sem);
} else if (p > 0) {
sem_wait(sem);
parentfn();
sem_post(sem);
int status;
wait(&status);
sem_destroy(sem);
} else {
// error
}
// Clean up
munmap(mem, pagesize);
You could also use a mutex in a shared memory region, but you need to make sure to create with non-default attributes with the process-shared attribute said to shared (via pthread_mutexattr_setpshared(&mutex, PTHREAD_PROCESS_SHARED)) in order for it to work.
This ensures that only one of childfn or parentfn will execute at any given time, but they could run in either order. If you need to have a particular one run first, start the semaphore off with a count of 1 instead of 0, and have the function that needs to run first not wait for the semaphore (but still post to it when finished). You might also be able to use a condition variable, which has different semantics.
A mutex should be able to solve this problem. Lock the mutex before the call to fork and have the 1st function excute as normal, while the second tries to claim the mutex. The 1st should unlock the mutex when it is done and the second will wait until it is free.
EDIT: Mutex must be in a shared memory segment for the two processes
Safest way is to use a (named) pipe or socket. One side writes to it, the other reads. The reader cannot read what has not been written yet.
Use a semphore to ensure that one starts before the other.
You could use an atomic variable. Set it to zero before you fork/thread/exec, have the first process set it to one just before (or better, after) it enters the function, and have the second wait while(flag == 0).
I have a function say void *WorkerThread ( void *ptr).
The function *WorkerThread( void *ptr) has infinite loop which reads and writes continously from Serial Port
example
void *WorkerThread( void *ptr)
{
while(1)
{
// READS AND WRITE from Serial Port USING MUXTEX_LOCK AND MUTEX_UNLOCK
} //while ends
}
The other function I worte is ThreadTest
example
int ThreadTest()
{
pthread_t Worker;
int iret1;
pthread_mutex_init(&stop_mutex, NULL);
if( iret1 = pthread_create(&Worker, NULL, WorkerThread, NULL) == 0)
{
pthread_mutex_lock(&stop_mutex);
stopThread = true;
pthread_mutex_unlock(&stop_mutex);
}
if (stopThread != false)
stopThread = false;
pthread_mutex_destroy(&stop_mutex);
return 0;
}
In main function
I have something like
int main(int argc, char **argv)
{
fd = OpenSerialPort();
if( ConfigurePort(fd) < 0) return 0;
while (true)
{
ThreadTest();
}
return 0;
}
Now, when I run this sort of code with debug statement it runs fine for few hours and then throw message like "can't able to create thread" and application terminates.
Does anyone have an idea where I am making mistakes.
Also if there is way to run ThreadTest in main with using while(true) as I am already using while(1) in ThreadWorker to read and write infinitely.
All comments and criticism are welcome.
Thanks & regards,
SamPrat.
You are creating threads continually and might be hitting the limit on number of threads.
Pthread_create man page says:
EAGAIN Insufficient resources to create another thread, or a system-imposed
limit on the number of threads was encountered. The latter case may
occur in two ways: the RLIMIT_NPROC soft resource limit (set via
setrlimit(2)), which limits the number of process for a real user ID,
was reached; or the kernel's system-wide limit on the number of
threads, /proc/sys/kernel/threads-max, was reached.
You should rethink of the design of your application. Creating an infinite number of threads is not a god design.
[UPDATE]
you are using lock to set an integer variable:
pthread_mutex_lock(&stop_mutex);
stopThread = true;
pthread_mutex_unlock(&stop_mutex);
However, this is not required as setting an int is atomic (on probably all architectures?). You should use a lock when you are doing not-atomic operations, eg: test and set
take_lock ();
if (a != 1)
a = 1
release_lock ();
You create a new thread each time ThreadTest is called, and never destroy these threads. So eventually you (or the OS) run out of thread handles (a limited resource).
Threads consume resources (memory & processing), and you're creating a thread each time your main loop calls ThreadTest(). And resources are finite, while your loop is not, so this will eventually throw a memory allocation error.
You should get rid of the main loop, and make ThreadTest return the newly created thread (pthread_t). Finally, make main wait for the thread termination using pthread_join.
Your pthreads are zombies and consume system resources. For Linux you can use ulimit -s to check your active upper limits -- but they are not infinite either. Use pthread_join() to let a thread finish and release the resources it consumed.
Do you know that select() is able to read from multiple (device) handles ? You can also define a user defined source to stop select(), or a timeout. With this in mind you are able to start one thread and let it sleeping if nothing occurs. If you intent to stop it, you can send a event (or timeout) to break the select() function call.
An additional design concept you have to consider is message queues to share information between your main application and/or pthread. select() is compatible with this technique so you can use one concept for data sources (devices and message queues).
Here a reference to a good pthread reading and the best pthread book available: Programming with POSIX(R) Threads, ISBN-13:978-0201633924
Looks like you've not called pthread_join() which cleans up state after non-detached threads are finished. I'd speculate that you've hit some per process resource limit here as a result.
As others have noted this is not great design though - why not re-use the thread rather than creating a new one on every loop?
Is there a function analogous to IsBadReadPtr in Unix? At least some functionalities of IsBadReadPtr?
I want to write a procedure which would react if something bad happens to a process (like SIGSEGV) and recover some information. But I want to check the pointers to make sure that the data is not corrupt and see if they can be accessed safely. Otherwise the crash handling procedure itself will crash, thus becoming useless.
Any suggestions?
The usual way to do this on POSIX systems is to use the write() system call. It will return EFAULT in errno rather than raising a signal if the memory cannot be read:
int nullfd = open("/dev/random", O_WRONLY);
if (write(nullfd, pointer, size) < 0)
{
/* Not OK */
}
close(nullfd);
(/dev/random is a good device to use for this on Linux, because it can be written by any user and will actually try to read the memory given. On OSes without /dev/random or where it isn't writeable, try /dev/null). Another alternative would be an anonymous pipe, but if you want to test a large region you'll need to regularly clear the reading end of the pipe.
How can you do it?
You try to do it and then handle the error.
To do this, first you set up a sigsetjmp and a SIGSEGV signal handler. Then attempt to use the pointer. If it was a bad pointer then the SIGSEGV handler is called and you can jump to safety and report the error to the user.
You can never tell "whether a pointer can be accessed safely", on Windows or on Unix. But for some similar information on some unix platforms, check out cat /proc/self/maps.
I ran into the same issue trying to read a 'pixel' from a framebuffer while running Ubuntu from within a virtualbox. There seemed to be no secure way to check access without crashing or acutally hanging gdb. The suggestion made by StasM hinted me towards to following working 'local' solution using fork.
void *some_address;
int pid = fork();
if (pid== 0)
{
someaddress[0] = some_address[0];
_exit(123);
}
bool access_ok = true;
int status;
int result = waitpid(pid, &status, 0);
if (result == -1 || WIFEXITED(status) == 0 || WEXITSTATUS(status) != 123)
{
access_ok = false;
}