Results 1 to 6 of 6

Thread: Too many CommRing subscribers bug

  1. #1
    Registered User
    Join Date
    Dec 2011
    Location
    York
    Posts
    2

    Too many CommRing subscribers bug

    hi there,

    i am using the commring to get data to a lot of channel plugins. the problem is that lightwave start to behave buggy (saving the scene and loading objects does not work anymore) when too many instances subscribe to the commring (about 10 - 50. i need around 500).

    the question is if there are any alternatives or solutions to commring, like tcp/ip to exchange data between different architextures (channel/displacement).

    thanks.

  2. #2
    Code Muppet evenflcw's Avatar
    Join Date
    Feb 2003
    Location
    Stockholm, Sweden
    Posts
    2,642
    Unfortunately, comring is a fail for anything serious. It can't even handle a ping-pong (in lscript; sdk I don't know; calls to comringmsg are ignored within comring event function; it's a broadcaster, not a communications system!). I think what you might be seeing is each of your instances event functions are called up within the same thread and hitting a limit or it's just too slow and LW decides lscript has had enough time executing and moves on. LW won't wait forever. I think this behaviour is documented aswell.

    Other options...

    There's always globalstore... which for windows stores data in the registry (mac I dont know). There's no way to clean it up(!) from lscript so don't go bananas. It will overwrite as long as you use the same key.

    There's IPC, supposedly superseded and "obsolete". But you never know. New doesn't always mean better.

    There's the file approach, but that's likely very taxing at 500 writer/readers.

    You could always write a custom lscript class in C/C++ (need to be recompiled for all platforms) or just move development over to sdk completely.
    Last edited by evenflcw; 12-07-2011 at 12:19 PM.

  3. #3
    Code Muppet evenflcw's Avatar
    Join Date
    Feb 2003
    Location
    Stockholm, Sweden
    Posts
    2,642
    About the save and load. Are you detaching from the comring in destroy() callback (or earlier for certain)? And only attaching once per instance?

  4. #4
    Registered User
    Join Date
    Dec 2011
    Location
    York
    Posts
    2
    thanks, evenflcw. yes, i am attaching each instance only once to comring. and would detach in destroy if the instances were removed. but the comring makes lightwave (mac) behave odd anyway. it's easy to reproduce. just write a channel script. attach to comring in the create function. and clone the object with the script attached 100 times. lightwave will fail.

    were can i get IPC documentation? if this doesn't work the file approach would be my last hope.

  5. #5

  6. #6
    Super Member vncnt's Avatar
    Join Date
    Sep 2003
    Location
    Amsterdam
    Posts
    1,584
    Old issue but there is a work-around that I just implemented and for now it seems to work fine.

    Bi-directional communication with comring is possible if you separate the two communication processes.

    Simply invoke the return call inside (at the end of) the ComRingHandler udf, using a boolean, and immediately call requpdate().
    In the reqredraw udf, check if that boolean is true.
    If set to true, reset the boolean and call a function that sends a return message.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •