Re: Re: [boost] Next revision of boost::thread

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-09 06:58:08

> From: Beman Dawes <bdawes_at_[hidden]>
> At 03:03 PM 1/8/2003, William E. Kempf wrote:
> 
>  >The sched_fifo, sched_rr, sched_other, scope_process, and scope_system
>  >values are implementation defined, and on POSIX correspond to SCHED_FIFO, 
> 
>  >SCHED_RR, SCHED_OTHER, PTHREAD_SCOPE_PROCESS and PTHREAD_SCOPE_SYSTEM
>  >respectively.
> 
> Do these values apply reasonably well to Windows?

Yes, in that you can fullfill the requirements of POSIX here on the Windows platform.  But that's true only because you can report at run time that some values are unsupported.  In point of fact, the only values that are usable on Windows are SCHED_OTHER and PTHREAD_SCOPE_SYSTEM.

However, the other possibilities are essential for realtime programmers, and can't be factored out because any platform, even one as prevelant as Windows, does not support them.
 
>  >thread::cancel() indicates that the thread of execution should throw
>  >thread_cancel at the next call to a "cancellation point".
>  >
>  >thread::test_cancel() is a "cancellation point" and will throw
>  >thread_cancel if thread::cancel() has been called on the current thread
>  >of execution.
>  >
>  >thread::sleep() and thread::yield() have not changed, except they are now 
> 
>  >considered "cancellation points" and may throw thread_cancel.
> 
> Are there other cancellation points?

Yes.  Significant to Boost.Threads are the condition wait operations.  Most others are std:: functions, such as read/write, for which Boost can't offer much of a solution but I'll have to document for the standard.
 
> Is there a way to force preemptive cancellation?

Just to be clear, what do you mean by "preemptive cancellation"?
 
> Given that there has been a great deal of concern about cancellation, I'd 
> like to see a fuller explanation of the cancellation model you are using. 
> Also a simple example or two.

There will be.  I plan to work on the documentation next... but there were enough questions about the design of attributes that I thought I'd post early.
 

William E. Kempf
wekempf_at_[hidden]