Author: Vincent Diepeveen
Date: 14:04:29 04/25/01
Go up one level in this thread
On April 25, 2001 at 10:00:29, Robert Hyatt wrote:
>On April 25, 2001 at 07:42:55, Vincent Diepeveen wrote:
>
>>On April 24, 2001 at 23:50:37, Robert Hyatt wrote:
>>
>>>On April 24, 2001 at 22:50:41, Hristo wrote:
>>>
>>>>select(..) doesn't do it. ;-(((
>>>>wish it did!!!!
>>>>select(..) works within a different domain and in general
>>>>can not compare to WaitForMultipleObjects. ;-(
>>>>WaitForMultipleObjects is, kind of like, select(..) on steroids!
>>>>...
>>>>The unix style is to keep things simple, which pays off when there
>>>>is good design!
>>>>
>>>>hristo
>>
>>basically i want 2 things
>> a) i want a search process/thread to idle
>> b) when the i/o process decides that it is time to let the
>> search start i want to *directly* let the search wake up.
>>
>>what i do now is similar to:
>> for( ;; ) {
>> sleep(100);
>> if( sharedtree->gosearch || sharedtree->quit )
>> break;
>> }
>>
>>I don't want to waste 100ms for each process!
>
>First, sleep(100) is _not_ sleeping for 100ms. :) you are off by several
>orders of magnitude there. man 3 sleep gives this:
>SYNOPSIS
> #include <unistd.h>
>
> unsigned int sleep(unsigned int seconds);
>
>That is the POSIX standard for sleep().
Yes you are right, i forgot. For linux i use
usleep()
for windows i use
Sleep()
Going to look into the select function
>
>
>>
>>WaitForMultipleObjects is not using 100ms as far as i know to
>>wake up!
>>
>>What to do in linux to get same effect?
>
>if it is as you describe it, I would use "select()". Have the "I/O thread"
>send me a message when there is something for me to do. every so often, I
>"select()" on the pipe to see if there is data. If not, I continue searching.
>It doesn't block if I put the time-out value at zero.
>
>An alternative would be to have the I/O thread send the search thread a
>"signal" when it has information to pass to it, which would avoid the
>select() polling test completely.
>
>
>
>
>
>
>
>>
>>>why can't you produce the same effect with a group of descriptors? Writing
>>>to such a descriptor from the "other end" will set that condition so that
>>>select() will terminate... IE it seems like a small kludge, but it would
>>>seem to allow the same sort of capability...???
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.