From owner-freebsd-hackers  Tue Feb 27  6:33:50 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61])
	by hub.freebsd.org (Postfix) with ESMTP id D8AD637B718
	for <freebsd-hackers@freebsd.org>; Tue, 27 Feb 2001 06:33:42 -0800 (PST)
	(envelope-from usebsd@free.fr)
Received: by smtp.nettoll.com; Tue, 27 Feb 2001 15:31:49 +0100 (MET)
Message-Id: <4.3.0.20010227153039.00dd4f00@pop.free.fr>
X-Sender: usebsd@pop.free.fr
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Tue, 27 Feb 2001 15:34:51 +0100
To: Marc W <mwlist@lanfear.com>, freebsd-hackers@freebsd.org
From: mouss <usebsd@free.fr>
Subject: Re: Where can I find out rules on blocking in threads?
In-Reply-To: <200102270121.RAA39980@akira.lanfear.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 17:21 26/02/01 -0800, Marc W wrote:
>hello!
>
>     I'm running into a problem with some threading using pthreads in an
>application i'm writing for FreeBSD.
>
>     The application basically
>
>     1. initializes some UI goo (but doesn't start any of it UP) using a
>GUI framework (Qt)
>     2. creates a FIFO, and then spawns a thread
>     3. this new thread then does:
>
>             fifo = open(fifoPath, O_RDONLY);
>
>     4. after the new thread is spawned, the application is supposed to
>then continue initialization, showing the main window and continuing on
>happily.
>
>
>     Now, the problem is that when step 3 above blocks on the open(2)
>call (as it should, since the other end of the pipe isn't opened yet),
>the whole application is frozen, and the main thread can't continue
>with GUI processing, and the app appears to die.
>
>     What is goofy is that this works just fine under Linux.  So,
>FreeBSD has slightly different blocking rules or something -- but I
>don't understand them.  It also hangs under Solaris 8/Intel.
>
>     So, the question is:  how can I find out what these differences are
>and try to get around them.   I'm using this to limit instances of my
>program to one, and need a named pipe instead of just a lock file so
>that new instances can communicate any arguments they might have been
>given, etc ...
>
>
>     any suggestions?

depens on how long it blocks? is it indefinitely blocking or for some time?
in the latter, you might use a sleep() in the child before the open().
Does the parent wait for its child (the thread that does the open fifo thing)?

can you provided a small piece of code that shows this behaviour?

cheers,
mouss


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message