No, that wasn't a reason at all. The real reason was that QNX didn'tWhatever that is, and whether it is local or remote, it is irrelevant. The
'interface' piece (i.e., the part dealing PURELY with interfacing the user)
by itself needs to be multithreaded if you ever hope to provide any decent
level of user experience. The only other alternative is splitting 'lenghty'
operations into chunks and handling them one by one, as Photon docs suggest.
Of course that in the end is nothing more than a rather lame
pseudo-multithreading that requires extra work and attention from you and
does not work too well anyway. The only reason they had to come up with a
design marvel like that is that the Photon libs were not thread-safe.
have threads at the time.
Besides, splitting the work into little chunks and doing them one at a
time in a workproc is *not* the only alternative to threads. Calling
PtBkgdHandlerProcess() often enough from various places in your code is
another one. In many cases, it's no worse than using threads --
especially if the code also wants to update widgets occasionally and
even if you used threads, you'd need to synchronize them anyway to make
sure that the window you're trying to update hasn't been closed.