On 10.08.2020 14:05, William F Pokorny wrote:
> Something is running too slow is the non helpful, short answer, I didn't 
> post yesterday - because it sound to me ears a little snarky despite 
> being accurate... :-)

No, that is pretty much the only answer available.

> Reasons could be many. Paging (using too much memory). Systems is 
> otherwise overloaded etc - or just slow.

Well, really slow. Remember that this means messages take 10 seconds to 
be passed from one thread to the next. Normally threads should be called 
every few milliseconds. If the operating system needs ten seconds to 
switch threads, something is wrong, or the receiving end is "gone", 
meaning it crashed. The later is way more likely for a simple scene.

> If the message hasn't somewhere been assembled from parts and pieces, 
> it's probably a 'kTimeoutErr' using a 10 (second?) default set 
> indirectly by 'kDefaultTimeout'.

Indeed.

> The only use of kTimeoutErr sits in a chunk of remaining 'c' code inside 
> the message passing system (source/povms/povms.c). If it is this error, 
> it can happen when sending a stream of data - somewhere.

The code isn't remaining, it is intentionally C code, so it can be 
ported really everywhere and run on a very low level, with some of the 
message passing APIs around and interact with the thread management 
directly. It will also work even if basically all memory is exhausted by 
using some private pool. For those who want a C++ API, there is one, of 
course. It sits on top of the C code.

> If you can compile yourself, there looks to be a _DEBUG macro in the 
> message code which when set extends the timeout to 100 (seconds?) if 
> running that bit of code under a debugger. Other debugging / workarounds 
> would require much more twiddling.

The question is not where the message is sent, but where it should be 
received. The whole POVMS code has extensive debugging support that can 
be enabled by macros.

> Aside: I've been digging around again in the frontend code and looking 
> some at this message passing system. Error wise, all over in the 3.7 
> code, there is a fair bit of error handling that looks to have been left 
> hanging - incomplete / not fully flushed out. It would certainly be 
> helpful in this case to know more about the 'message' being sent on the 
> timeout.

No, this isn't really the case. By the time you get into trouble with 
the message passing, you are already in such a mess that you likely 
cannot recover in a meaningful way. The most likely cause of the message 
passing to stall for a simple scene is actually that the receiving side 
crashed in some way, i.e. by an exception that left the message handler 
in an unexpected way.

> Aside 2:
> I don't much understand the message passing system code, but it looks 
> like most information internally is getting passed around using it. I 
> think the idea was to eventually be able to support rendering remotely 
> on a large cluster of machines with a single controlling gui/entity.

No, it is also a core of the threading functions. What it really does it 
provide a separation between the frontend and the backend such that you 
can actually render multiple scenes or images of a scene at the same 
time. It also allows you to do this while the frontend GUI and the 
backend(s) run in separate processes. It also is the code used for 
render continuation (that actually works even if you switch systems in 
between) and a bunch of other stuff.

> The remote capability doesn't especially interest me with povr, and I'm 
> carrying the question: Should I try replace it / change it / simplify 
> the vfe/povms stuff... Don't know.

Suggestion: If you don't understand some code, it is a clear indication 
you should stay away from it until you do ;-)

VFE is basically a quick solution Chris Cason implemented early in the 
3.7 development because something was needed for the Windows frontend. 
It is by no means required. It is just a collection of stuff that is 
really mostly meant for the Windows frontend, and does not work all that 
well for a command line frontend. Actually, in 3.7 the command line 
frontend used to be in there and would compile by enabling the main 
function - I know because this feature was a major part of the 
development process of 3.7.

> (1) - On unix/linux, if you are not running 'povr,' you are mostly not 
> seeing any actual command line / ini parsing errors except a catch all 
> thing which,

Well, the code could be added. But you are right that the error handling 
of INI files was not finished in time.

Thorsten

Post a reply to this message