[erlang-questions] Best way to kill an async thread in a linked in driver?
Mazen Harake
mazen.harake@REDACTED
Fri Aug 13 18:25:26 CEST 2010
You're actually spot on about the timeout "tuning", I was playing with
that yesterday and my conclusion was (I read up on it a little) that
most people aren't able to tell the small differences in delays that can
occur between pressing a key and reacting to it.
Anyway I did implement this version now and I'm going to try out the
driver_select() version later to compare in terms of user-experience and
complexity of the code. If the driver_select() version works out as well
as the version I have now (not yet pushed to branch) I might go with that.
Thanks for the feedback!
/Mazen
On 13/08/2010 03:29, Nicholas Frechette wrote:
> It is pretty standard to pool for a shared variable and exit/clean up
> on state change. I've done this hundred of times.
> Alternatively, you might be able to flag that thread as a daemon
> thread. Typically programs exit when only daemon threads remain and
> all non-daemon threads have completed/exited. I know they have that
> with C++ on solaris, java, python, etc. Not sure about your specifics
> though but worth checking it out.
>
> You can play with the timeout value of your polling. High values mean
> that you'll be penalized when exiting but you'll be decreasing the
> delay in reading while lower values will do the opposite. Just find a
> decent balance for your app but afaik, few people have problems
> waiting 1-2s for an app to exit.
> Nicholas
>
> On Thu, Aug 12, 2010 at 6:21 PM, Mazen Harake
> <mazen.harake@REDACTED
> <mailto:mazen.harake@REDACTED>> wrote:
>
> Sorry, I should have been a bit more clear:
> I need to do things in Erlang space while I'm waiting for input,
> such as telling the driver to print out a character at pos y,x.
>
> This is the reason I can't be blocked in the driver.
>
> Still... I may have missed something, you are more than welcome to
> enlighten me :):)
>
> /M
>
>
> On 13/08/2010 01:14, Mazen Harake wrote:
>
> 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?
>
> Thanks for feedback,
>
> /M
>
> 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.
>
> Kresten
>
> On Aug 12, 2010, at 10:31 , Mazen Harake wrote:
>
> It was late yesterday and despite 2 coffees and a
> nice breakfast I
> still can't solve this one. Maybe a nudge in the right
> direction anyone?
>
> Scenario:
> I have a linked in driver; cecho [1], when ever I want
> to read input I
> disable input to Erlang (-noinput) and use the getch()
> function in C
> instead (never mind why ;)). This function is run in a
> seperate async
> thread using driver_async() [2][3], and blocks at
> getch(). When a
> character is read it sends a message back to Erlang
> (driver_output())
> and then the thread exits, when the message comes back
> to Erlang the
> character is sent to the requester and the thread is
> restarted (which
> again blocks at getch()).
>
> Later if I do an erlang:halt(0) ("graceful halt") the
> thread is still
> lingering despite having closed the port[4] (which,
> Afaik should close
> the thread as well) but it seems stay alive somehow.
> erlang:halt(1) kill
> it immediately so it is not a problem.
>
> Questions:
> 1) Is my "analysis" correct? Is this infact what is
> happening? Anyone
> who can explain this behaviour (I.e. why it lingers on)?
>
> 2) If Question 1 then; what is the best way to kill
> the thread when I
> exit? driver_async_cancel() only works for threads
> that are not
> executing (according to Documentation) so what to do?
> I did an ugly
> workaround which sets a global flag and then I timeout
> the getch()
> operation and read for ERR. If I get an ERR I just
> read the abort flag
> and if it is set I just die otherwise I try to getch()
> again. This
> avoids hanging around for more then a tenth of a
> second but it is pretty
> ugly in my oppinion and I'm forced to go into
> halfdelay mode which means
> I can not allow this option outside of the driver
> because I become
> dependent on it. I'd rather do it the "right way" if
> there is such a way.
>
> References: (Links given as commit Ids so that if
> someone searches then
> they get relevant code and not the latest)
> [1]
> http://github.com/mazenharake/cecho/tree/199fd342ba186e1154c32dbfdcf2d9222e25f9f4
>
>
> [2]
> http://github.com/mazenharake/cecho/blob/199fd342ba186e1154c32dbfdcf2d9222e25f9f4/c_src/cecho.c#L119
>
> static void request(ErlDrvData drvstate, char
> *buf, int buflen) {
> state *st = (state *)drvstate;
> driver_async(st->drv_port, NULL, loop_getch, (void
> *)st, NULL);
> }
>
> [3]
> http://github.com/mazenharake/cecho/blob/199fd342ba186e1154c32dbfdcf2d9222e25f9f4/c_src/cecho.c#L557
>
> void loop_getch(void *arg) {
> state *st = (state *)arg;
> ei_x_buff eixb;
> int keycode;
> ei_x_new_with_version(&eixb);
> keycode = getch();
> integer(&eixb, keycode);
> driver_output(st->drv_port, eixb.buff, eixb.index);
> }
>
> [4]
> http://github.com/mazenharake/cecho/blob/199fd342ba186e1154c32dbfdcf2d9222e25f9f4/src/cecho_srv.erl#L76
>
> terminate(_Reason, State) ->
> do_call(State#state.port, ?ENDWIN),
> do_call(State#state.port, ?CURS_SET, ?ceCURS_NORMAL),
> erlang:port_close(State#state.port),
> erl_ddll:unload("cecho").
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org <http://erlang.org>
> mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe;
> mailto:erlang-questions-unsubscribe@REDACTED
> <mailto:erlang-questions-unsubscribe@REDACTED>
>
> Kresten Krab Thorup, CTO, Trifork
>
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org <http://erlang.org> mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> <mailto:erlang-questions-unsubscribe@REDACTED>
>
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org <http://erlang.org> mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> <mailto:erlang-questions-unsubscribe@REDACTED>
>
>
More information about the erlang-questions
mailing list