Hi Phil,
I think the easiest solution for your problem is something like this:
#include
#include
volatile unsigned long len = 0;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
static void cleanup_handler(void *arg) {
(void)pt
Philip S. Schulz wrote:
P.S:: Attached is the full example.
Oh, well, apparently I'm too dumb to use my mail reader correctly... it
is at http://aliue.homeunix.net:8000/threads.c
Phil.
___
freebsd-hackers@freebsd.org mailing list
http://lists.fre
Hi!
From the what's-wrong-with-my-code department...
I'm having trouble with two threads accessing a queue. One thread
writes to it while the other one reads from the queue. I'd like the
consumer to run until the main thread (which is the producer) decides
that the consumer thread should ex
On Tue, Oct 22, 2002 at 08:24:05AM +0300, Peter Pentchev wrote:
> On Mon, Oct 21, 2002 at 10:31:48PM +0200, Linus Kendall wrote:
> [snip]
> >
> > That was very thorough, thanks! Now I at least have a notion of what
> > is going on. Since this is slightly urgent I guess a hack into the
> > libcurl
Bruce M Simpson wrote:
> On Mon, Oct 21, 2002 at 02:03:52PM -0700, Terry Lambert wrote:
> > It is more correct to say that libcurl makes an assumption about
> > signal delivery which is not guaranteed by POSIX, and therefore
> > libcurl will not work with *any* POSIX compliant threads
> > implement
On Tue, 22 Oct 2002, Peter Pentchev wrote:
> On Tue, Oct 22, 2002 at 12:31:32PM +0100, Bruce M Simpson wrote:
> > On Mon, Oct 21, 2002 at 02:03:52PM -0700, Terry Lambert wrote:
> > > It is more correct to say that libcurl makes an assumption about
> > > signal delivery which is not guaranteed by P
On Tue, Oct 22, 2002 at 12:31:32PM +0100, Bruce M Simpson wrote:
> On Mon, Oct 21, 2002 at 02:03:52PM -0700, Terry Lambert wrote:
> > It is more correct to say that libcurl makes an assumption about
> > signal delivery which is not guaranteed by POSIX, and therefore
> > libcurl will not work with *
On Mon, Oct 21, 2002 at 10:31:48PM +0200, Linus Kendall wrote:
[snip]
>
> That was very thorough, thanks! Now I at least have a notion of what
> is going on. Since this is slightly urgent I guess a hack into the
> libcurl source code to try to remove the sigalarms would do the trick
> (in my case
On Mon, Oct 21, 2002 at 04:48:34PM +0300, Peter Pentchev wrote:
> On Mon, Oct 21, 2002 at 03:24:08PM +0200, Linus Kendall wrote:
> > m?n 2002-10-21 klockan 14.45 skrev Peter Pentchev:
> > > On Mon, Oct 21, 2002 at 01:35:59PM +0200, Linus Kendall wrote:
> > > > Hi,
> > > >
> > > > I'm trying to por
Linus Kendall wrote:
> That was very thorough, thanks! Now I at least have a notion of what
> is going on. Since this is slightly urgent I guess a hack into the
> libcurl source code to try to remove the sigalarms would do the trick
> (in my case). In the general case it seems like there's a rather
mån 2002-10-21 klockan 21.44 skrev Peter Pentchev:
> On Mon, Oct 21, 2002 at 06:33:46PM +0200, Linus Kendall wrote:
> > Answer inline below.
> >
> > m?n 2002-10-21 klockan 15.50 skrev Peter Pentchev:
> > > On Mon, Oct 21, 2002 at 04:48:34PM +0300, Peter Pentchev wrote:
> > > > On Mon, Oct 21, 2002
On Mon, 21 Oct 2002, Peter Pentchev wrote:
> Okay, I can see what the problem is; however, I have absolutely no idea
> how it is to be solved :(
>
> The DNS resolution routines of libcurl use alarm() as a timeout
> mechanism for the system DNS resolving functions. To enforce the
> timeout even wh
12 matches
Mail list logo
