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