odin-lang
core:thread get_name/set_name
With macos not supporting setting the name of another thread, should we just not support it anywhere, so we have a consistent API?
I'm wondering whether adding a possibility to thread.create_*/thread.start to add a name for the newly created thread would be an idea, instead of adding a thread.set_name proc?
Similar to how Java does it with new Thread(Runnable, name), this way thread creation/starting could set the name upfront, as this name is merely a "debugging" thing and I don't see a reason why someone would arbitrarily change one.
With macos not supporting setting the name of another thread, should we just not support it anywhere, so we have a consistent API?
I'm wondering whether adding a possibility to
thread.create_*/thread.startto add a name for the newly created thread would be an idea, instead of adding athread.set_nameproc?Similar to how Java does it with
new Thread(Runnable, name), this way thread creation/starting could set the name upfront, as this name is merely a "debugging" thing and I don't see a reason why someone would arbitrarily change one.
Good idea!
With macos not supporting setting the name of another thread, should we just not support it anywhere, so we have a consistent API?
Yeah, I was also hesitant about this but It feels weird to shun others capability just to make this one feels consistent. I think the solution to have all the OS refer to the calling thread is pretty neat though. but, I would gladly comply if it’s somehow idiomatic.
I'm wondering whether adding a possibility to
thread.create_*/thread.startto add a name for the newly created thread would be an idea, instead of adding athread.set_nameproc?Similar to how Java does it with
new Thread(Runnable, name), this way thread creation/starting could set the name upfront, as this name is merely a "debugging" thing and I don't see a reason why someone would arbitrarily change one.
I also think this is a good idea. but, I’m not sure about not adding thread.set_name at all though. even though I don’t personally use it.
@GloriousPtr thoughts?
I would still get rid of the set_name, and instead move this name to thread.create, where something like __unix_thread_entry_proc and similar would set the name on the running thread itself
@laytan I just looked at how Zig does it, and it simply returns an error.Unsupported, perhaps we should just also do that? :slightly_smiling_face:
https://ziglang.org/documentation/master/std/#std.Thread.setName
Seems like a reasonable tradeoff right?, additionally still keep the idea of an initial thread name param.
If we’re going down the thread.create_with_name* route, I think we don’t need to have a get_name. we have to make a struct field (thread.Thread) for the name to make it callable from inside the thread, so if we want to retrieve the name, we can just t.name or something like that.
I think we don’t need to have a get_name. we have to make a struct field (thread.Thread) for the name to make it callable from inside the thread
I disagree, I don't see a reason to add this field to a Thread, the kernel already represents the single point of truth for this value. This isn't a hot spot either so in my opinion nothing wrong with performing a syscall here to obtain the value.
My idea was to do something like this:
thread.create :: proc(procedure: Thread_Proc, priority: Thread_Priority = Thread_Priority.Normal, name: Maybe(string) = nil) -> ^Thread
(Similarly for all those other variants) Which then calls the respective _set_name proc in the threads __entry_proc, as this would get rid of the issue that darwin does not support changing arbitrary thread's names
I disagree, I don't see a reason to add this field to a Thread, the kernel already represents the single point of truth for this value. This isn't a hot spot either so in my opinion nothing wrong with performing a syscall here to obtain the value.
yeah, I suppose you’re right on not getting rid of get_thread. But we do need to add a field in thread.Thread in order to pass it inside __unix_thread_entry_proc and __windows_thread_entry_proc though… right?
But we do need to add a field in thread.Thread in order to pass it inside __unix_thread_entry_proc and __windows_thread_entry_proc though… right?
Looks like it, can't use context._internal here because the windows thread entry proc may not be called immediately