Most probably threading issues



  • On 11/02/2016 at 11:05, xxxxxxxx wrote:

    User Information:
    Cinema 4D Version:    
    Platform:      
    Language(s) :

    ---------
    I've continued making some progress but now I have a pretty "expensive" operation that breaks randomly  I think it is related to threading since if I limit the amount of vertex it never crashes and works perfectly.

    Obviously I tried StopAllThreads but I had no luck.

    Using core messages from help doesn't fit my needs (some different funcions inside my object, custom type return etc).

    Any idea?

    In other hand this is not my case but anyway I'm curious about this I've readed on the help file:

    A common problem is that you need to update/add materials inObjectData::GetVirtualObjects(). That is the wrong place!

    That's ok but what if I need to modify my object throught time?

    Thank you in advance!



  • On 12/02/2016 at 01:25, xxxxxxxx wrote:

    Hello,

    can you give us some information about what you are actually doing and what you are trying to achieve?

    It seems that you implement a ObjectData plugin and GetVirtualObjects()? Is that correct? Or are you creating a deformer? What are you doing in GetVirtualObjects()?

    Please notice that GetVirtualObjects() is not about modifying any object. This function is used to create virtual sub-object. These objects have to be completely re-created if something relevant changed. And it is only allowed to create these sub-objects in GetVirtualObjects().

    Please also never call StopAllThreads() in GetVirtualObjects() since GetVirtualObjects() itself is called in a threaded context. See Important Threading Information.

    Best wishes,
    Sebastian



  • 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)..


Log in to reply