On 3/24/10 9:13 PM, Joerg Sonnenberger wrote:
> The point is that you don't really get that. Consider mutexes currently
> hold by a different thread in the original program. May I strongly
> advise you to first identify exactly where Ruby is failing and based on
> that let us decide how it can be f
On 3/24/10 3:32 PM, Joerg Sonnenberger wrote:
>> Consider the method to become a daemon, you fork() then let the child
>> continue. Surely we're not saying you cannot use pthread_create() there...
>
> You are confusing something here. The constraints apply to
> multi-threaded programs. Most daemo
On 3/24/10 3:09 AM, Andrew Doran wrote:
The comment that pthread_* functions cannot safely be used in the forked
child is not QUITE what I understand to be what POSIX has in mind. They
say only one thread is running (that is, the child's MAIN thread).
Creating another thread afterwards should be
On 3/23/10 7:08 PM, Joerg Sonnenberger wrote:
> On Tue, Mar 23, 2010 at 07:03:11PM -0700, Michael Graff wrote:
>> I'd like to commit it (and request a pull-up to netbsd-5). Any reason I
>> shouldn't?
>
> What is the real problem here? fork(2) of a multithreaded pr
It appears that this patch works. I believe the submitter was working
on Ruby 1.9 on NetBSD, and ran into this (which I also did.)
The supplied patch works on my netbsd-5 branch test box, and should also
apply for current.
I'd like to commit it (and request a pull-up to netbsd-5). Any reason I
