ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
any idea why this sigsuspend is getting called soon after thread tries to write on fd=3. After this call my thread waits for the signal for for ever. I am not sure, which signal it is.
My process is deamon so stdin/stdout/err is closed.
I have compiled dmalloc library with my program and during this run dmalloc is active by setting DMALLOC_OPTIONS env variable.
Looks like I found the problem.
The problem what I think is
1). thread1 is about to lock a mutex but at the same time it got schduled out.
2). thread2 frees the c++ object containing the same mutex. The thread's code gets the same mutex lock before deleting the object.
3). Now when thread1 again gets scheduled, it tries to lock the deleted object's mutex and so it waits for ever since the destructor for the object never unlocks the mutex. However it calls pthread_mutex_destroy () on the mutex.
4). Now since that object is deleted for ever and object is unreferenced so thread2 or anybody else never call unlock for same mutex.
Note: My object's destructor calls pthread_mutex_destroy () on same mutes.
So there are little unexplain things are there but I dont like the idea of triying to aquire a lock on deleted object. I solved this problem by puting mutex out of the object at global level. This solution worked for me now.