Ruby 1.9 as default

Steve Wills swills at mouf.net
Tue Jun 5 13:44:02 UTC 2012


>
> On Jun 5, 2012, at 1:52 AM, Konstantin Belousov wrote:
>
>> On Mon, Jun 04, 2012 at 08:25:08PM -0400, Steve Wills wrote:
>>> On 06/01/12 22:30, Stanislav Sedov wrote:
>>>>
>>>> I'm not sure it's a good idea.
>>>> Ruby 1.9 still has some nasty bugs on FreeBSD, related to the threads
>>>> and
>>>> fork.  That is fork in ruby 1.9 hangs sometimes...
>>>
>>> The ONLY thing I can find is this:
>>>
>>> http://bugs.ruby-lang.org/issues/2097
>>>
>>> which implies that it's fixed. If there's more to this issue than
>>> "broken on 7.3 and earlier", PLEASE let me know.
>>
>> If ruby indeed does what the bugs described, that is, calls non-async
>> signal safe functions from the threaded process after fork, then you
>> are guaranteed to get random hangs sometimes.
>
> Actually, the problem I'm trying to debug right now is more weird.
> When I run mono via system(3) from the ruby 1.9 process (I mean,
> exactly system(3), not via some ruby wrapper) twice, it hangs on some
> umtx the second time.  This works all the time.
>
> I'm still trying to track it down in mono, though it's not clear how
> this can happen at all.  Isn't execve(2) used by system(3) is supposed
> to clear everything (mutexes at least)?
>

Is this perhaps the -pthread issue I hit with perl? The issue is that if
you call (dlopen, exec, whatever) a threaded app from a non-threaded on,
it hangs due to the fact that libc takes shortcuts and doesn't initialize
thread related things in non-threaded apps. The solution is to build with
-pthread. (I may be describing the problem wrong, but the solution of
building with -pthread works.)

Perhaps we need to build ruby with -pthread?

Steve




More information about the freebsd-ports mailing list