Let's simplify and say its behavior is to "create UP TO n threads".  Deciding 
to create fewer -- either because there is some system limit, or the size of 
the image is too small to justify that many threads -- is perfectly acceptable 
behavior and not considered an error.

I'm not hugely against having it return a bool, but I think we should try to 
make it always "succeed" no matter what.  Failure should mean "it failed to do 
the image operation", NOT "it chose to use a different number of threads than 
was originally requested."



On Jun 13, 2012, at 3:03 PM, Stefan Stavrev wrote:

> About the parallel_image function in src/maketx/maketx.cpp. I am using it as 
> example to make a function for Over.
> 
> 1. I am thinking about having a return type bool instead of void. Imagine if 
> you called parallel_image with nthreads = 100 and for some reason it did not 
> succeed in creating 100 threads. Reason being wrong version of boost or else. 
> If I want to do my operation on 100 processors and for some reason it still 
> was done on 1, I would like to know about that :). We could return false in 
> such cases where number of threads was specified but still that many threads 
> can't be created.

> 
> 2. If you agree parallel_image to return bool, how to handle this case:
> 
> R.spec().image_pixels() < 1000 && nthreads > 1, which means that there are 
> not enough pixels in the image to parallelize the operation and number of 
> threads is specified. Should we fail because we specified nthreads for 
> example to be 5 and yet because of not enough pixels it still will be done on 
> 1 thread?
> 
> 3. Possible general rules:
> 
> If for whatever reason we can't create as many threads as specified by the 
> parameter nthreads, then fail and return false.
> 
> Another possible general rule is, succeed only if we can create more than 1 
> threads and fail otherwise. Having more than 1 thread is the reason why we 
> call parallel_image in the first place.
> 
> Stefan
> 
> 
> 
> 
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected]


_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to