Date: Wed, 12 Nov 2008 15:22:11 -0500 From: Mikhail Teterin <mi+mill@aldan.algebra.com> To: Daniel Eischen <deischen@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, stable@freebsd.org Subject: Re: dlopen-ing a library with OpenMP by a non-OpenMP process Message-ID: <491B3AF3.9020606@aldan.algebra.com> In-Reply-To: <Pine.GSO.4.64.0811121509330.4280@sea.ntplx.net> References: <491B1BD2.4050903@aldan.algebra.com> <20081112194350.GJ47073@deviant.kiev.zoral.com.ua> <491B3270.5080402@aldan.algebra.com> <Pine.GSO.4.64.0811121451260.4280@sea.ntplx.net> <491B3653.5080209@aldan.algebra.com> <Pine.GSO.4.64.0811121509330.4280@sea.ntplx.net>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?491B3AF3.9020606>