Most probably threading issues
-
On 12/02/2016 at 02:14, xxxxxxxx wrote:
Cannot disclosure so much about my work (will be public in some months) but I'm generating a kind of connection to other API.
Being specific I'm opening a file at Message(...) case:MSG_MENUPREPARE and the API using that file creates meshes and materials.
Aboug GetVirtualObjects() I'm not doing that right now but I'm embarased to admit that it sounds for me the easiest way, how could I check if time changes to recreate the meshes?
Thank you for your great support.
-
On 12/02/2016 at 03:49, xxxxxxxx wrote:
Well you certainly can not have a thread started in MSG_MENUPREPARE that modifies the scene. That
will (obviously) run into race conditions and likely into a crash. If you have a long-living operation to
generate meshes and material, either block the user until its done or do it in the background but in
a separate (your own allocated) BaseDocument (if even necessary, you could also keep track of them
in a maxon::BaseArray) and then insert the objects and materials into the current when you're done. -
On 12/02/2016 at 05:47, xxxxxxxx wrote:
Ufff the more I learn the more I know I have no idea.
I think that operate over a new BaseDocument seems logic but when I should copy that new doc to the current one? Also how I could block the user?
-
On 12/02/2016 at 05:51, xxxxxxxx wrote:
Edit: I'm only using the doc for read the time so it shouldn't be the problem.
-
On 12/02/2016 at 06:30, xxxxxxxx wrote:
Reading can certainly be a problem too since the document is not constant (ie. static -- not changig).
You can block the user by simply doing stuff in the main thread (eg. Message() method -- most [if not
all] messages sent by Cinema are sent in the main thread) and not returning until its done. You usually
want to give the user feedback so you can open a dialog and display a progress bar and update it. -
On 12/02/2016 at 09:50, xxxxxxxx wrote:
I've used SpecialEventAdd but since my routines trigger a external GUI it seems that StopAllThreads is not enough since meanwhile the GUI is shown I still can move viewports etc.
-
On 12/02/2016 at 11:28, xxxxxxxx wrote:
More on this: now it works on a single thread but still crashing in two parts of the code
sometimes at
for(int mfaceindex=0; mfaceindex<numfaces;mfaceindex++)
polys[mfaceindex] = CPolygon(v0, v1, v2);
when mfaceindex is a "high" number over 4000 or something like that (but a random value each time), obviously it was created like
PolygonObject* mObject = PolygonObject::Alloc(numfaces, numvertex);and other times at
void PolygonObject::Free(PolygonObject* & bl)
_
_
Any idea? -
On 12/02/2016 at 15:58, xxxxxxxx wrote:
You're passing numfaces and numvertex to Alloc() in the wrong order.
-
On 13/02/2016 at 02:25, xxxxxxxx wrote:
You are right but it looks a bit confusing
static PolygonObject* Alloc(Int32 pcnt, Int32 vcnt);I was assuming that pcnt means poly count and vcnt vertex count.
-
On 13/02/2016 at 05:13, xxxxxxxx wrote:
That's an easy problem to solve: Do not assume but read the
documentation.
It explicitly states "pcnt - The point count." and
"vcnt - The polygon count." See PolygonObject::Alloc().On a side note, I agree that it looks confusing.
-
On 13/02/2016 at 06:10, xxxxxxxx wrote:
Yeah it is confusing but if I remember right this is a legacy issue because it references the german words "punkt" (means point) count and "viereck" (polygon or rather quadrangle) count.
I forgot where I grabbed this (it's been years ago)..