[Haskell-cafe] Help with async library and killing child processes

Branimir Maksimovic branimir.maksimovic at gmail.com
Wed Mar 18 10:18:22 UTC 2020


That's just library, not built into language. You can do it with forkIO 
as I do it per specifics

of application.

Greets,
Branimir.

On 3/18/20 11:06 AM, YueCompl wrote:
> No, not to cancel a thread, but the business task on that thread's way 
> ahead.  That's what Go's Context is designed for.
>
>   * About Go context from: https://blog.golang.org/context
>
>     At Google, we require that Go programmers pass a Context parameter
>     as the first argument to every function on the call path between
>     incoming and outgoing requests. This allows Go code developed by
>     many different teams to interoperate well. It provides simple
>     control over timeouts and cancelation and ensures that critical
>     values like security credentials transit Go programs properly.
>
>     Server frameworks that want to build on Context should provide
>     implementations of Context to bridge between their packages and
>     those that expect a Context parameter. Their client libraries
>     would then accept a Context from the calling code. By establishing
>     a common interface for request-scoped data and cancelation,
>     Context makes it easier for package developers to share code for
>     creating scalable services.
>
> I (and seems Windows api too) strongly agree that cancelling a thread 
> is problematic:
>
> https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-terminatethread
>
> TerminateThread is a dangerous function that should only be used in 
> the most extreme cases. You should call TerminateThread only if you 
> know exactly what the target thread is doing, and you control all of 
> the code that the target thread could possibly be running at the time 
> of the termination. For example, TerminateThread can result in the 
> following problems:
>
>   * If the target thread owns a critical section, the critical section
>     will not be released.
>   * If the target thread is allocating memory from the heap, the heap
>     lock will not be released.
>   * If the target thread is executing certain kernel32 calls when it
>     is terminated, the kernel32 state for the thread's process could
>     be inconsistent.
>   * If the target thread is manipulating the global state of a shared
>     DLL, the state of the DLL could be destroyed, affecting other
>     users of the DLL.
>
>
>> On 2020-03-18, at 17:16, Branimir Maksimovic 
>> <branimir.maksimovic at gmail.com 
>> <mailto:branimir.maksimovic at gmail.com>> wrote:
>>
>> I'm pretty sure you can't cancel goroutine. Actually I have
>>
>> very bad experience with thread cancelation. Therefore flags
>>
>> passed via channels/mvars or shared flags are used to stop
>>
>> threads.
>>
>> Greets,
>> Branimir.
>>
>> On 3/18/20 10:10 AM, YueCompl wrote:
>>> Idiomatic resource leakage prevention in short.
>>>
>>> An app wants to be as responsive to its users as practically 
>>> feasible, it would try multiple paths to load-balanced resources, 
>>> and use the first response that come back, then cancel other paths. 
>>> Cancellation can help reducing vain computation in such 
>>> architectures, sometimes largely enough.
>>>
>>>> On 2020-03-18, at 16:58, Branimir Maksimovic 
>>>> <branimir.maksimovic at gmail.com 
>>>> <mailto:branimir.maksimovic at gmail.com>> wrote:
>>>>
>>>> What's wrong with forkIO?
>>>>
>>>> Greets,
>>>> Branimir.
>>>>
>>>> On 3/18/20 9:37 AM, YueCompl via Haskell-Cafe wrote:
>>>>> If not for tight loops or other CPU intensive tasks, you may be 
>>>>> interested in Edh, which introduces Go's goroutine to GHC runtime. 
>>>>> But Edh threads add much higher overhead on top of GHC threads, so 
>>>>> there's a price to pay for simplicity of end programmer's job.
>>>>>
>>>>> It's briefly described at 
>>>>> https://github.com/e-wrks/edh/tree/master/Tour#program--threading-model . 
>>>>> This is very new and I'm right now actively working on it for PoC 
>>>>> of an STM powered in-memory graph database implementation.
>>>>>
>>>>> Best regards,
>>>>> Compl
>>>>>
>>>>>> On 2020-03-18, at 11:15, Niklas Hambüchen <mail at nh2.me 
>>>>>> <mailto:mail at nh2.me>> wrote:
>>>>>>
>>>>>> I've you're new to async, also check out my recent rework of the 
>>>>>> docs that talk about this topic specifically:
>>>>>>
>>>>>> https://github.com/simonmar/async/pull/105/files
>>>>>>
>>>>>> (To be available in the next release of async.)
>>>>>> _______________________________________________
>>>>>> Haskell-Cafe mailing list
>>>>>> To (un)subscribe, modify options or view archives go to:
>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>>> Only members subscribed via the mailman list are allowed to post.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Haskell-Cafe mailing list
>>>>> To (un)subscribe, modify options or view archives go to:
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>> Only members subscribed via the mailman list are allowed to post.
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200318/4960b8da/attachment-0001.html>


More information about the Haskell-Cafe mailing list