>From: "Bryan K. Ogawa" <[EMAIL PROTECTED]>
>
>If anyone who knows about the state of the FreeBSD threads implementation
>could go through it and check it for factual errors, missing bits, etc.
>then that would be great.
in your section about common reentrant extensions, you mention the IPv6
api
>From: Charles Randall <[EMAIL PROTECTED]>
>
>Is there a reason that ADNS won't work for this?
>
>http://www.chiark.greenend.org.uk/~ian/adns/
in addition to the other reasons mentioned, it won't work for me because
it's not a part of the os. as an application developer, i'd expect the
basic s
i've just received confirmation from the author of the KAME resolution code
that it isn't at all thread safe:
>Sure. As noted in name6.c, thread related stuff is not implemented yet.
>Since our resolver code based on bind4 doesn't aware thread safeness,
>all I can do now would be only putting m
hackers,
i have a multithreaded app that makes heavy use of sockets. i'm seeing a
deadlock that looks like it's coming from getipnodebyname. it's my
understanding that this guy is supposed to be threadsafe, but comments like
this one in libc/net/getaddrinfo.c make me wonder:
* Issues to be
hackers,
i'm seeing some fairly odd behavior from accept(2) when the connecting
socket goes away at just the right time. the timing is fairly funky, so i
don't know if i can easily whip up a repro for this, but what i'm seeing is:
accept returns a positive value (ie: not an error), but sets t
>From: John Polstra <[EMAIL PROTECTED]>
>
>In article <[EMAIL PROTECTED]>, Greg Thompson
><[EMAIL PROTECTED]> wrote:
>
> > i'm having trouble with the runtime linker.
>
>What version of FreeBSD?
mortal sin #1. oops. 4.0-2714-STABLE.
>Is
hackers,
i'm having trouble with the runtime linker. it seems like a bug, but
perhaps there's something mystical i'm supposed to do to make this work.
the short version of what i'm seeing is this:
my app references symbols in a shared lib. the shared lib uses symbols in
another shared lib.
7 matches
Mail list logo
