> 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
> 
> 

where two or more processes or threads are asking for the same resource 
at the same time and each is waiting for the other to finish using that 
resource.

Post a reply to this message