Results 1 to 9 of 9

Thread: Terminate Lua thread

  1. #1
    Join Date
    Mar 2006
    Location
    Sydney, Australia
    Posts
    787

    Default Terminate Lua thread

    Hi,
    i want to use
    Code:
    [Thread] = thread.newthread([function], [parameters])
    and just in case something goes wrong, i want to terminate the thread after a set period of time.

    I was thinking of doing it like this

    Code:
    function func(par1,par2)
     while stopthred ~= false do
      print (par1,par2)
     end
    end
    
    thred = thread.newthread(func, {"param1", "param2"})
    stopthred = thred:waitforthread(100)
    So is this the way i should go about it or is there a way to terminate that i missed?

    thankyou

    Dan

  2. #2
    Join Date
    Mar 2006
    Location
    Sydney, Australia
    Posts
    787

    Default

    so.. this doesnt really do what i want it to, its ok for a simple example like the one i posted but if i call a function from an Lua class it cant terminate should it fail to return.

    What im trying to do is use Marcels AMG script for up to 5 tracks at once but if a 6th artist is queried before the 1st has finished i want to terminate the first.

    Is there a way to kill a specific thread?

  3. #3
    Join Date
    May 2004
    Location
    Cardigan, UK
    Posts
    9,278

    Default

    Unfortunately, the answer is no, there's no way to kill a thread

    Sounds as though what you need is a pool of worker threads as in the help example.

    I would recommend that if you are using mutexes then you should use pcall to protect the code that runs while the mutex is locked, otherwise any error will leave the mutex locked.
    --Rob

  4. #4
    Join Date
    Mar 2006
    Location
    Sydney, Australia
    Posts
    787

    Default

    Hi Rob,

    thanks for your help, but i dont think i need to use mutex's as each thread has its own variables, and i dont think i need workers because i dont want to make a thread wait, my aim is to control the number of active threads while still allowing new threads to spawn as required.

    I must admit my grasp of how it all works is pretty slim, when i looked at the help for mutex and cond i immediately reached for the too hard basket.

    I'll have a rethink and see if i can find another way to achieve my goal.

    cheers

    Dan

  5. #5
    Join Date
    Dec 2001
    Posts
    11,560

    Default

    Definitely do not want to kill threads... they should terminate gracefully.

  6. #6
    Join Date
    Mar 2006
    Location
    Sydney, Australia
    Posts
    787

    Default

    Hi Rob,
    Maybe i do need to use a mutex to protect the vars. Can i have a variable that is a member of multiple mutex's? So i can lock one file with a [Mutex]:lock() call to a mutex containg a file or all files with a [Mutex]:lock() call to another mutex that contains many files including the one protected by the other mutex.
    Thanks
    Dan

  7. #7
    Join Date
    May 2004
    Location
    Cardigan, UK
    Posts
    9,278

    Default

    It would be easier to see a concrete example of this
    --Rob

  8. #8
    Join Date
    Mar 2006
    Location
    Sydney, Australia
    Posts
    787

    Default

    I had a think about it and i guess it won't work, but this is what i want to do
    Code:
    AMGINFO.Mutex = {}
    
    AMGINFO.Mutex.Bio = { thread.newmutex(),
    AMGINFO[location].Biography 
    }
    
    AMGINFO.Mutex.Disco = { thread.newmutex(),
    AMGINFO[location].Biography 
    AMGINFO[location].AlbumList,
    AMGINFO[location].TrackList,
    AMGINFO[location].Review,
    AMGINFO[location].Pick,
    AMGINFO[location].Rating,
    AMGINFO[location].Genre
    }
    and then if i want to lock just AMGINFO[location].Biography use
    Code:
    AMGINFO.Mutex.Bio[1]:lock()
    and if i want to lock all vars including that one use
    Code:
    AMGINFO.Mutex.Disco[1]:lock()
    I actually didnt try it and at the moment i have not got the var duplicated in the two mutex's so i use
    Code:
    AMGINFO.Mutex.Bio[1]:lock()
    AMGINFO.Mutex.Disco[1]:lock()
    when i want to lock them all.

    Thanks for taking a look,

    Dan

  9. #9
    Join Date
    May 2004
    Location
    Cardigan, UK
    Posts
    9,278

    Default

    I would strongly advise against using two mutexes like this unless they are protecting completely different resources, ie there is no overlap. To access the bio then you'd really need to lock both of your mutexes. I'd stick to using a single mutex I think. If your threads need to do a lot of data processing then I'd suggest that they should each use local variables and only when all the processing is done then lock the mutex and update your main data structure.
    --Rob

Posting Permissions

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