On Tue, 25 Jan 2005 14:04:45 -0800, Julian Elischer <[EMAIL PROTECTED]> wrote: > > > Jose Hidalgo Herrera wrote: > > >The line causing the SEGFAULT is > >rc = pthread_create(&threads[t], NULL, PrintHello, (void *)t); > > > >Why?, because t is declared as: > >int t; > >then you say: > >args for start_routine in pthread_create are located in the address: t > > > >This will be what you want: > >rc = pthread_create(&threads[t], NULL, PrintHello, (void *) & t);
Yan is actually (almost) correct. He's is casting the int to a pointer type for the sake of the pthreads interface: the pointer is never dereferenced, and shouldn't cause a segfault. The lack of cast in "PrintHello" is probably the worst transgression. (Consider: "t" is a local variable, and its address won't change for any thread in the loop of "CreateThread". The code may have some type transgressions, but it's reasonably well formed) > probably we shouldn't crash the system however.. (it is crashing right? > that wasn't so clear to me). Given the stack trace, that's not happening (though I'll let Yan give the definitive answer). The stack trace includes "kse_sched_single()", which is a routine from libpthread, not the kernel (there's a kse_release symbol in libpthread and the kernel.) > >>what confuses me is that, if the system is out of memory, then i should > >>see the error returned from pthread_create() or calloc(), but not SEG > >>fault, or i must have missed something? (warning: there are many over-simplifications ahead) You should also be aware that FreeBSD can overcommit memory. Effectively, this means that a successful result from "malloc(X)" does not mean the system guarantees that X bytes of (real) memory are actually available: it means that this chunk of your process's address space has been carved out for you: the system may "over commit". The reasons and history for this are complex, but essentially, the kernel can either be generous, and open user programs up to faulting asynchronously (read: segfaulting if there no free memory at the time you first access a page), or be conservative - carefully track memory, possibly wasting resources (RAM or paging space) in order to guarantee that allocated memory is allways accessable. "SVR4" OSes like Solaris will generally not over commit, and guarantee synchronous failure for memory allocation, but will be more wasteful of resources. While BSD derived systems will indeed overcommit, at the expense of opening up user programs to the possibility of coping with pagefaults if they are not well behaved in terms of their memory usage. (I hope that's reasonably objective: _please_, everyone, don't offer opinions on what's "better" without creating a new thread) Cheers, Peadar. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
