RE: [Boost-Users] set thread priority
I'd think a relatively simple implementation would be to simply support them when possible, and otherwise turn all such calls into no-ops. Coming up with a range of priority values that would be portable shouldn't be too terribly difficult either. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard;
Mark Storer said:
I'd think a relatively simple implementation would be to simply support them when possible, and otherwise turn all such calls into no-ops.
That would be a major pain for users. If they aren't available, they shouldn't exist, and the hooks for conditional compilation should be provided (this is what POSIX does).
Coming up with a range of priority values that would be portable shouldn't be too terribly difficult either.
Actually, this *IS* the difficult part (well, beyond the design decisions). -- William E. Kempf
Bill,
Thanks for the explanation of your plans for thread priorities.
At the moment, as a work-around on win32, is it possible to
access the underlying windows thread handle, and set the
priority manually?
Thanks.
Aaron Boxer
boxerab@NOSPAMyahoo.com
--- In Boost-Users@y..., "William E. Kempf"
Mark Storer said:
I'd think a relatively simple implementation would be to simply support them when possible, and otherwise turn all such calls into no-ops.
That would be a major pain for users. If they aren't available, they shouldn't exist, and the hooks for conditional compilation should be provided (this is what POSIX does).
Coming up with a range of priority values that would be portable shouldn't be too terribly difficult either.
Actually, this *IS* the difficult part (well, beyond the design decisions).
-- William E. Kempf
boxerab said:
Bill, Thanks for the explanation of your plans for thread priorities. At the moment, as a work-around on win32, is it possible to access the underlying windows thread handle, and set the priority manually?
Unfortunately, no, though as a temporary solution you could hack this yourself. I hope to start releasing more of the stuff in thread_development shortly, however, and the thread class (although not finished) has a very high priority for me. -- William E. Kempf
participants (3)
-
boxerab -
Mark Storer -
William E. Kempf