{"push_id":862068138,"size":1,"distinct_size":1,"ref":"refs/heads/lg-thread","head":"a64271c7a1392f7e872ab2763b2b417cbbd697d2","before":"5a6a19c818301722aee9e958b83c001b91e76422","commits":[{"sha":"a64271c7a1392f7e872ab2763b2b417cbbd697d2","author":{"email":"f0a1ce6f80112d72f7276457fd261d671b827567@larrygritz.com","name":"Larry Gritz"},"message":"ImageInput: Add nthreads parameter to read_image, read_scanlines, read_tiles.\n\nThis allows control over thread spawning, similar to the parameter on\nthe various ImageBufAlgo functions. A value of 0 means to use the global\nOIIO::attribute(\"nthreads\") value (which in turn defaults to have a\nthread fan-out equal to the hardware concurrency). For a sole thread of\nexecution, you want a big fan-out for tasks that can be parallelized,\nwhereas when the calling function is one of many concurrent threads\nalready underway, you just want the work done directly by the calling\nthread, without spawning additional threads that will oversubscribe the\nhardware.\n\nThere are currently only a couple spots where ImageInput might spawn\nthreads. So this is primarily for future expansion, so that we might add\nmore multithreading and give appropriate control to the calling\napplication.\n\nThe reason that we want per-call overrides rather than relying solely on\nthe global \"nthreads\" attribute is that OIIO may be used by multiple\nparts of an application (or multiple dependent libraries or plugins,\neach unaware of the others), and so it is not particularly safe under\nthose circumstances to set the global value and assume that it will stay\nthat way.\n\nThis is a preliminary effort for design review. Obvious extensions, if\npeople like the way this is going, would be to add the nthreads\nparameter to the \"native\" versions (read_native_tiles,\nread_native_scanlines), the \"deep\" versions, and and corresponding\nroutines in ImageOutput. Also we should add a method to ImageBuf that\ncan set an \"nthreads\" paremeter for any underlying ImageInput or other\noperations done internal to the IB.\n\nIt is worth discussing alternatives. I admit that the idea of scattering\n\"nthreads\" parameters widely through the APIs is one that does give me\nsome pause. But it has worked well for IBA, and at the moment I don't\nhave a better idea for ImageInput/ImageOutput. Feedback appreciated.","distinct":true,"url":"https://api.github.com/repos/lgritz/oiio/commits/a64271c7a1392f7e872ab2763b2b417cbbd697d2"}]}