guy keren <[EMAIL PROTECTED]> writes: > the fact that in this specific code you didn't have a problem, does not > prove it is correct. the debugger can only be used to show when you _do_ > have a race condition - it cannot be used to prove there is _no_ race > condition.
No argument here. I did say Nadav was right, I only pointed out that it was not the cause of the problem - I tried his suggestion. > > Besides, return from main(), as well as any exit(), should > > terminate the process (including any threads), freeing the memory by > > independent means, not execute the rest of the code, buggy as it may > > be. > > not true at all. the main thread is just a thread. when it calls exit(), > the other threads may still be executing, and theoretically, there could > be a context switch in the middle of the exit() function, and this might > cause a race. Theoretically. Actually, I was quoting Stevens, whom I thought to be a reliable source, but now I am not so sure (see below)... > when you handle multi-threading, you are not allowed to say "it won't > happen" This is not specific to multithreading. > as for the bug itself - you are not allowed to pass a NULL pointer as the > first parameter of pthread_create() To tell you the truth, I was counting on you, choo, specifically, when posting the message ;-). This solved the problem indeed. I did not invent passing a NULL pointer to pthread_create() - I lifted it from UNP as well. Apparently the thread library became less permissive since then. Thanks to everybody: choo, Nadav, Omer. -- Oleg Goldshmidt | [EMAIL PROTECTED] "If it ain't broken, it has not got enough features yet." ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
