Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: girder coroutine handling

  1. #1
    Join Date
    May 2004
    Location
    Darmstadt Germany
    Posts
    358

    Default girder coroutine handling

    Hello community,

    I am currently having an issue with the realtime behaviour of girder and I am wondering if coroutines are the answer. Maybe someone of you can help me with this.
    The situation: I use girder as my home automation system and (for more than 200 devices) as my tv control application in the same time. Therefore I am polling several local/online rest interfaces (e.g. to Philips hue, my broadband router to retrieve the local hosts, ... ) multiple times in a minute. This blocks all girder ressources for several seconds (up to 10 seconds depending on the complexity of the call). In this moment girder is not able to perform realtime functions like translating IR-signals or switching lights immediately.
    My question: Is using coroutines the solution for my problem? I could imagine that girder should pack the long lasting remote call into an extra thread to stay responsive in the main thread. Would this work?
    Second question: The long lasting calls are mostly initiated by a single function call which splits into multiple subcalls and these are resulting in asynchronious callbacks. Is it the case that all of this subcalls and callbacks are executed in the coroutine or are they handled by the main thread again (which would mean that my plan to relieve the main thread is not working)?

    I hope my description is sufficient to describe my isse well enough so that someone can answer.

    regards,

    mhund
    Last edited by mhund; September 25th, 2016 at 05:17 PM.

  2. #2
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,553

    Default

    You probably need to start using threads for those long lived scripts. Cooroutines by themselves do -not- start threads.
    Ron
    No support through PM

  3. #3
    Join Date
    May 2004
    Location
    Darmstadt Germany
    Posts
    358

    Default

    Hm. I thought coroutines is the way how lua splits into threads. But when I get you right, coroutines are still running in the same thread and therefore blocking each other from running in parallel? Do you have more information about the kind of threads you are mentioning? Did not find something in the reference manual.

  4. #4
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,553

    Default

    Have a look in the manual under scripting/thread
    Ron
    No support through PM

  5. #5
    Join Date
    May 2004
    Location
    Darmstadt Germany
    Posts
    358

    Default

    Ah. Thanks. Will give it a try :-)

  6. #6
    Join Date
    May 2004
    Location
    Darmstadt Germany
    Posts
    358

    Default

    I think I have the idea of it but some more examples would be helpful :-/

  7. #7
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,553

    Default

    The manual shows:
    Code:
    thread.newthread( function( a,b )
        print(a,b)
    end, {"hello", "there" })
    That's all there is too it. ( Well almost )
    Ron
    No support through PM

  8. #8
    Join Date
    May 2004
    Location
    Darmstadt Germany
    Posts
    358

    Default

    Thanks. Well - this was the part I got already :-)

    I am not sure how far I have to deal with this conflict management thing "mutex". I understand the idea behind it but I don't know if it is necessary of if it brings complexity to my code which I could prevent.

  9. #9
    Join Date
    May 2004
    Location
    Darmstadt Germany
    Posts
    358

    Default

    What about my Second question: The calls I want to put into a separate thread are a single function call which splits into multiple subfunction calls and these are resulting in asynchronious callbacks. Are all the subcalls and callbacks executed in the separated thread or are they handled by the main thread again? Maybe a dumb question but I am not sure.

  10. #10
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,553

    Default

    :-) Sorry!

    Threads as you see can be started easy. Mutex can protect parts that may only be accessed by one thing at a time ( like counters ). Threads by their nature bring complexity I'm afraid, there is potential for deadlocks and race conditions with threads and mutexes so be very careful.

    First things to do before splitting things off is figuring out where your slowdowns are. Are you using any wait functions? Any long calculations? If so that is what you need to get off the main thread. The transport functions -should- not block as they are all asynchronous.

    When you call a transport function from a thread the callback that you get when the async operation completes is actually back on the main Girder thread. The thread you started most likely has stopped running by then.
    Ron
    No support through PM

Page 1 of 3 123 LastLast

Posting Permissions

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