[D-runtime] A mechanism to kill threads

Sean Kelly sean at invisibleduck.org
Wed May 16 15:59:59 PDT 2012


That forces the GC to expose functionality for acquiring any relevant locks for something that really has nothing to do with memory allocation., and still only takes care of one potential deadlock, albeit a common one.  Critical sections would help as well (that's basically how pthread_cancel() works), but applying them to this case would be tricky.

On May 16, 2012, at 3:54 PM, Alex Rønne Petersen wrote:

> Again, this boils down to knowing what you're doing. You should NOT be
> killing a thread if there is any chance whatsoever that the thread
> could be doing GC allocation while you do it.
> 
> That said, I'm not convinced that this is a problem that we cannot
> work around; I think that if kill() would acquire the global thread
> lock, this problem could be prevented from happening.
> 
> Regards,
> Alex
> 
> On Thu, May 17, 2012 at 12:52 AM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> On Wednesday, May 16, 2012 14:44:12 Sean Kelly wrote:
>>> If the killed thread even has a chance of allocating memory ir could be
>>> killed while inside the GC and lock all threads out of the GC forever.
>> 
>> Ouch.
>> 
>> - Jonathan M Davis
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime



More information about the D-runtime mailing list