From owner-freebsd-stable@FreeBSD.ORG Wed Nov 12 20:22:18 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46104106564A for ; Wed, 12 Nov 2008 20:22:18 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6CD8FC16 for ; Wed, 12 Nov 2008 20:22:17 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 5159 invoked from network); 12 Nov 2008 20:22:13 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Nov 2008 20:22:12 -0000 Message-ID: <491B3AF3.9020606@aldan.algebra.com> Date: Wed, 12 Nov 2008 15:22:11 -0500 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: Daniel Eischen References: <491B1BD2.4050903@aldan.algebra.com> <20081112194350.GJ47073@deviant.kiev.zoral.com.ua> <491B3270.5080402@aldan.algebra.com> <491B3653.5080209@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , stable@freebsd.org Subject: Re: dlopen-ing a library with OpenMP by a non-OpenMP process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 20:22:18 -0000 Sent by Daniel Eischen: > No, I simply meant that you saw it was returning bad system > call from sem_init/ksem_init. Instead, I suspected, that it is the OpenMP, that's at fault. I'm sorry for failing to live up to your expectations of a true FreeBSD user. > A little investigation would have turned up the reason. If you want > to debate whether or > not P1003_1B_SEMAPHORES should be standard, that is another > issue, which I might actually agree with. Well, I'm sure, the debate on including P1003_1B_SEMAPHORES by default has already raged before... No, what I was suggesting, was that sem_init -- not the system call, but the C-function -- should be more intelligent in detecting such situations and reporting them instead of crashing... Either the C-function, or, maybe, the no-op implementation of (k)sem_init in the kernel ought to have told me (even if only in the kernel log), that I need to kldload sem and refer to the man-page. That's what well-integrated Operating Systems do, anyway... -mi