[erlang-questions] Best way to kill an async thread in a linked in driver?

Mazen Harake mazen.harake@REDACTED
Fri Aug 13 18:17:33 CEST 2010


  Ah! I had completely over looked the driver_select() and thought that 
he was talking about simply select() which didn't make sense. I'll try 
this out later today or tomorrow, thanks for the explaination.

/Mazen

On 13/08/2010 06:43, Steve Vinoski wrote:
> On Thu, Aug 12, 2010 at 6:14 PM, Mazen Harake
> <mazen.harake@REDACTED>  wrote:
>> On 12/08/2010 14:42, Kresten Krab Thorup wrote:
>>> I'd write the driver using select and non-blocking reads; that way you
>>> would not need async threads at all.
>>   Hmm... I'm not sure what you mean but the part I do understand is that
>> select() blocks... right? I can't have anything that blocks in the driver
>> since I must be able to interact with it as I'm waiting for input. E.g. I
>> need to update a certain part of the screen even if the user is not pressing
>> any buttons.
>>
>> I don't see how select() would make any difference? Perhaps I misunderstood
>> you, could you explain a bit more on how that would work? Or perhaps point
>> me to some direction?
> What Kresten is essentially recommending is that you make the file
> descriptor from which you're reading characters non-blocking and then
> register it into the emulator's event loop via driver_select(). Once
> your file descriptor has something to read, the emulator will call
> your code via your driver's ready_input callback. At that point you
> can read your character(s) from your fd and process them pretty much
> like you're doing now. You can read the fd until you get EAGAIN or
> EWOULDBLOCK, at which point there's nothing left to read, and you can
> then return from your ready_input callback. The emulator will call you
> every time there's something to read until you unregister the fd.
>
> As Kresten said, no async thread required.
>
> --steve



More information about the erlang-questions mailing list