DragonFly BSD
DragonFly users List (threaded) for 2005-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Blocking on multiple threads with timeout

From: EM1897@xxxxxxx
Date: Mon, 28 Feb 2005 10:54:43 -0500

In a message dated 2/27/2005 3:39:31 AM Eastern Standard Time, Andrew Hacking <ahacking@xxxxxxxxxxxxxxx> writes:

>On Mon, 2005-02-28 at 10:58, Jonathon McKitrick wrote:
>> : Instead, you may want to re-consider the software that *allows* your
>> : worker threads to block indefinitely, because it probably won't be
>> Well, on the first round, we check for the device we are talking to (serial,
>> GPIB, IP, USB, etc.).  That is where a timeout is most likely to occur.  But
>> this operation is performed serially, so no threads are spawned.  But after
>> that, we spawn threads to initialize each device (which is full of motors
>> and such) and this can take a minute or more.  Basically, I should be able
>> to write the init thread to timeout if the 'ok' reply has not been received
>> after the 'init' command has been sent to the device.  Is that what you are
>> saying?
>Yes, pass a timeout to your init function (or via some other means if
>required), and ensure that the code does not block indefinitely.  Your
>main thread can just perform a pthread_join() on all the worker threads,
>and *know* that it wont block much longer than the timeout.
>> : operations that can block indefinitely.  This is much easier and more
>> : reliable than the above high wire act, and often avoids the need for a
>> : "manager" thread altogether.
>> I'd like to start the init threads, put the id's in an array, block until
>> they are all done, then continue.  Each thread should have its own timeout
>> handling internally.

It seems to me that you are complicating the issue for no
good reason. Why are you using threads at all?

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]