Issue #673 wontfix

0.9: Threads don't block during file parsing

xgoff avatarxgoff created an issue

currently, love.thread.newThread() (or Thread:start()?) doesn't block while the file given to it is being parsed. this makes detection of syntax errors in the new thread's script quite difficult since Thread:getError() might not be updated in time, and the parent thread can't wait on the child thread without deadlocking since the latter cannot execute anyway.

since the parsing process is opaque to lua code (and relatively fast for most scripts), it would make sense for the relevant function to block until parsing is completed, so that Thread:getError() would be guaranteed to return a syntax error (if one happened) if called after that function.

NOTE: a workaround is to perform the syntax check via eg loadfile(), before creating the thread, but that's kinda ugly and redundant

Comments (8)

  1. Alex Szpakowski

    Bart van Strien pointed out that it's not really possible to continue blocking while parsing files require'd by the original thread file, since require is executed when the thread file is called rather than when it's parsed.

    It would seem inconsistent to error immediately for syntax errors in the thread file but error later for syntax errors in files require'd by the thread file, compared to always erroring later.

  2. xgoff

    sure, i'm not expecting requires performed in the thread file to block, since those would be indistinguishable from other runtime errors. it should be the thread code's responsibility to handle that (since it actually has the chance to prevent it via pcall). but as i mentioned, you have no (reliable) chance to catch a syntax error in the thread file itself

    i'm not sure it would really be inconsistent, though. yes, it's handling two cases of parsing errors differently, but that's because the functionality is different anyway, with the threading library acting like loadfile rather than require:

    x = love.thread.newThread(y) --> x = loadfile(y)
    x:start()                    --> x()
    
    -- also, newThread/start and loadfile fail silently, unlike require 
    

    that may or may not be how it works internally of course, but the similarities are there. imo this is more consistent

  3. Alex Szpakowski

    Thread:start starts the thread's main function in the separate thread. The thread's main function creates a new Lua state, initializes the standard Lua libraries, initializes the main love module, initializes the thread module, loads the Lua code originally passed into newThread, and executes it.

    As of yesterday, you can pass arguments to Thread:start which are accessible in the thread code with ....

  4. Bart van Strien

    Well, my problem is that I'm sure people will then say it's bugged because it only "gets" certain errors, I'd much rather tell people they need to check properly anyway. Speaking of which, I've been thinking about adding an event for a thread error.

  5. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.