New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
thread-safety and convenience of basePrint
#7
Comments
The above change does not keep the original Lua behaviour though, notably: the space after every item, no new line after the items, and printing to standard error rather than standard out by default. Also, why does |
Yes, the change linked up there is for my own use. The original function added a tab after each printed item instead of a space. And this does actually add a newline after the item set. Giving LState its own io.Writer is certainly an option. Not ideal though. For instance, in my case, I want all output to written to a single log file. Which would mean each LState would get the same file descriptor. This doesn't solve the thread safety issue. |
@jteeuwen - That sounds like an issue with your own code, not gopher-lua. You could easily solve this with a mutex + your own print function. The most suitable option is allowing a custom writer to be assigned per LState. In your own code you can then add a function to lock and unlock the writer which is assigned. |
I use the log package, which already deals with all of this. It was just a suggestion. It's up to yuin to decide what he deems reasonable. |
Threadings First, the LState(including the Default outputs Lua reference manual says about the
If you want to print values to anywhere but stdout, use Now, therefore, in consideration of the above, I would like to make no changes to GopherLua. |
I agree that you should keep with the standard. |
The
basePrint
function inbaselib.go
currently writes its output directly toos.Stdout
throughfmt.Print
and friends. This will cause problems when callingprint
from multiple goroutines/Lua threads. Notably, that multiplePrint
calls can have their output interwoven on the console when they both run in parallel. For example:Can, under certain conditions, give output like this:
Additionally, it would be nice if the host application could specify a different output target, aside from the default
os.Stdout
. For this reason, I'm wondering if it is not more convenient and safer to have it use Go'slog
package instead. This package takes care of both problems at once.The changes to this package can be as simple as:
The host now has the guarantee that logging stuff is thread safe and the output can be redirected to any target by calling
log.SetOutput(io.Writer)
.The text was updated successfully, but these errors were encountered: