OK, I have my own programming question. Not a homework. I am also
posting it to comp.unix.programming, but this list can be more
responsive.
I have the following trivial piece of code that I am trying to
compile with g++ (gcc-2.96-98) on RH 7.2 (Linux 2.4.9-13 on i686).
The code looks like C, bu
On Mon, Nov 26, 2001, Oleg Goldshmidt wrote about "threads question":
> static void* start(void* arg)
> {
> int c = *((int*)arg);
> free(arg);
> .
> }
>
> int main(void)
> {
> int* arg = NULL;
>
> if ((arg = (int*)
> -Original Message-
> From: Oleg Goldshmidt [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 27, 2001 1:58 AM
> To: [EMAIL PROTECTED]
> Subject: threads question
>
>
>
> OK, I have my own programming question. Not a homework. I am also
> posting it
Omer Musaev <[EMAIL PROTECTED]> writes:
> AFAIK, you should not "return NULL; " from a pthread, but rather
> "pthread_exit( NULL ); "
Then I get the same segfault stepping through pthread_exit().
I am looking at Stevens' UNP where he clearly says that the
start_routine (my start()) can return a
"Nadav Har'El" <[EMAIL PROTECTED]> writes:
> What is this last return statement?? Returning from main? That's not
> something you're supposed to do in a multithreaded program. It
> might, for example, free the entire malloc pool, including arg which
> is later freed in the second thread, causing
On 26 Nov 2001, Oleg Goldshmidt wrote:
> > What is this last return statement?? Returning from main? That's not
> > something you're supposed to do in a multithreaded program. It
> > might, for example, free the entire malloc pool, including argwhich
> > is later freed in the second thread, causi
On Mon, Nov 26, 2001, Oleg Goldshmidt wrote about "Re: threads question":
> > What is this last return statement?? Returning from main? That's not
> > something you're supposed to do in a multithreaded program. It
> > might, for example, free the entire m
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
> 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.
No,
