On Tue, Oct 15, 2002 at 04:43:37PM -0400, Roland McGrath wrote:
> > Ok, so we leak in hurd/lookup-retry.c and in sysdeps/mach/getloadavg.c,
> > sysdeps/mach/getsysstats.c, and sysdeps/mach/gettimeofday.c, in glibc.
>
> Yes. Given how often gettimeofday might be called, it probably makes sense
> t
> Ok, so we leak in hurd/lookup-retry.c and in sysdeps/mach/getloadavg.c,
> sysdeps/mach/getsysstats.c, and sysdeps/mach/gettimeofday.c, in glibc.
Yes. Given how often gettimeofday might be called, it probably makes sense
to cache the right once at startup instead of doing the system call every
On Sun, Oct 13, 2002 at 05:13:48PM -0400, Roland McGrath wrote:
> > * You should never call mach_thread_self(). If you need to call it,
> > don't call it a number of times linear to the running time of the
> > program. If you follow that rule, you could even get away with
> > deallocating
> * You can call mach_task_self() anytime you like. Never deallocate it.
That's right. Using the macro that is really just a variable and doesn't
diddle refs is not a very clear API, but we inherited it from CMU.
> * You should never call mach_thread_self(). If you need to call it,
> don't
On Sat, Oct 12, 2002 at 10:37:52PM -0400, Roland McGrath wrote:
> Generally speaking, leaking send rights should be considered like leaking
> memory and programs that leak any send rights are buggy. This goes for the
> thread and task send rights just like any other. The mach_task_self macro
> us
I understand the rationale for asserts like that. But they need not to leak.
And they are damn expensive to have done very often.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
> So you have asserts that have the side effect of leaking send
> rights?
I was working under the assumption that we do not deallocate send
rights returned by mach_thread_self. As I will now understand that
that assumption is wrong, I will correct the code.
My comment was more to justify the use
> > pthread just seem to trigger it by calling mach_thread_self often.
>
> As a side note, libpthread may call it a lot but only in asserts
So you have asserts that have the side effect of leaking send rights?
That's a) buggy because it leaks and b) not very good at having the code
with assertion
The reason fork hangs is because it calls assert (which means a printf)
while holding lots of locks. In particular it deadlocks on the dtable lock
in the backtraces you sent.
That is sort of a bug, in that an assert that managed to print out
something before crashing would be more helpful. You c
> pthread just seem to trigger it by calling mach_thread_self often.
As a side note, libpthread may call it a lot but only in asserts
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Sun, Oct 13, 2002 at 03:34:27AM +0200, Marcus Brinkmann wrote:
> What I don't know is where exactly the error occurs. Someone might want to
> step through thread_create to find out where the problem happens, or Roland
> might already know.
Clearly my cold is showing, as __thread_create is just
Hi,
I found one problem with pthreads, but it is not pthread specific. pthread
just seem to trigger it by calling mach_thread_self often. Not sure.
The problem was in fork(). The assertion at line 446 in sysdeps/mach/hurd/fork.c
was failing. The error returned is EKERN_UREFS_OVERFLOW.
12 matches
Mail list logo
