|
Boost Users : |
Subject: Re: [Boost-users] Thread Interruption Best Practice
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-03-21 03:06:10
Hi,
if I understand your problem you want the thread blocking in select to return? If yes you could add add pipe to select for reading which will wake you up from select and indicate you that you have to terminate.
Oliver
-------- Original-Nachricht --------
> Datum: Mon, 21 Mar 2011 10:45:46 +1300
> Von: Dom Driver <domdriver_at_[hidden]>
> An: boost-users_at_[hidden]
> Betreff: [Boost-users] Thread Interruption Best Practice
>
> Hi List,
>
> I'm fairly new to boost, and have recently started to use the threading
> system from v1.46 in an app I'm writing targeting Linux. This was primarily
> to enable execution of threads to be blocked until a condition variable is
> set, at which point the thread is kicked awake and actions whatever is
> waiting to be done.
>
> All good, and all working as expected.
>
> However, I've got another thread which sits listening for data on a socket
> using a Linux select() call. This blocks until data is available for
> reading, at which point it is read from the socket as expected. This also works
> fine, except on termination of the application.
>
> Using native Linux implementations, a signal can be sent to the thread
> that is blocking on the select() call, at which point the call returns, and
> the EINTR error is set. I can therefore check for this condition and handle
> appropriately.
>
> Is there a way to send a Linux signal (or boost equivalent) to a specific
> boost thread to emulate this behaviour?
>
> Failing that, is there an alternative implementation of the classic Linux
> select()/read() functionality using boost classes? I had a look at the
> async I/O library and it seems a bit convoluted.
>
> TIA,
>
> Dom
>
>
>
-- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net