GC deadlocks on linux
ketmar via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Thu Feb 19 15:10:34 PST 2015
On Thu, 19 Feb 2015 17:12:02 -0500, Steven Schveighoffer wrote:
> On 2/19/15 12:01 PM, ketmar wrote:
>> On Thu, 19 Feb 2015 16:33:58 +0000, Byron Heads wrote:
>>
>>> Now I am not sure. This code runs correctly:
>>
>> as i told you before, `fork()` is hard. you can experiment for monthes
>> seeing strange bugs here and there, and seeing no bugs, and strange
>> bugs,
>> and...
>
>
>> there are alot of things going on under the hood, and alot of things
>> aren't. strictly speaking you *CAN'T* get cloned process in the same
>> state as it's parent. it may work, though, if stars are in a good
>> shape.
>
> Just as an example, Sociomantic uses a concurrent GC based on forking.
it's completely different thing. *this* use of fork -- to make "snapshot"
of running application -- is perfectly ok.
> I'm not sure what the issue here is, but I don't think forking is as
> unstable as you seem to think, or maybe I'm reading this wrong. I can
> agree there are many gotchas with forking.
forking is stable -- in the sense that it's doing exactly what it was
asked to do. but that can be something different from what someone
*think* it should do. `fork()` is described as "making a copy of the
running process", and it's right... for some extent. but what "copy" is
exactly? all threads except the one are lost. pid and tid was changed.
what about signal masks? and thousands of other things which are taken as
granted -- thread locks, for example, which can store tid of the thread
that was aquired the lock? what about other libraries, which can do
things you don't know about? and so on...
sure, `fork()` is perfectly usable... when you know what is going on and
can foresee all consequences. but it's hard, and i'd better recommend to
avoid `fork()` at all if programmer is not closely familiar with the
thing. in most cases avoiding `fork()` is much easier than trying to find
out what (can/is) going wrong with the program that was working ok
without forking.
what i trying to tell OP is that if his code working ok without forking,
it's much easier to just go this way and forget about `fork()`, not
wasting time to find out what is wrong with it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20150219/8e570c63/attachment.sig>
More information about the Digitalmars-d-learn
mailing list