I have the feeling this is a very advanced and very specific question, still I would appreciate indications on how to avoid the uncomfortable corner I find myself in, namely that I found no alternative to goroutine id for my (quite complicated) use case.
Let me explain: My Go interpreter gomacro (https://github.com/cosmos72/gomacro) is almost complete: it supports interfaces, functions, methods, goroutines, type inference, untyped constants etc. It allows to freely mix interpreted and compiled code, which means for example that you can call Interp.Eval() on the string "func fibonacci(n int) int { if n <= 2 { return 1 }; return fibonacci(n-1) + fibonacci(n-2) }" and the interpreter will create a function whose reflect.Type is EXACTLY func(int) int, it can be passed to compiled Go code, and it will behave as expected (i.e. compute fibonacci numbers). Such function INTENTIONALLY does not accept additional arguments, as for example a caller-provided context.Context, goroutine id, or similar. The reason is simple: to provide maximum compatibility with compiled code, a func foo(int) int { ... } must have type "func (int) int" in all cases: be it compiled code, or a function created at runtime by the interpreter, or whatever its origin. The problem is: where can I store debugger information, as for example whether single-stepping is enabled or not? Such information is clearly specific per-goroutine: when you are debugging some interpreted code, you want it to check whether single-stepping mode is enabled and, in case, inform the debugger that it suspends itself in order to be debugged, waiting for debugger commands before continuing. But you surely do NOT want ALL OTHER interpreted code running in other goroutines to start executing in single-stepping mode too, inform the debugger that they suspend themselves too in order to be debugged, waiting for debugger commands. This would mean that debugging interpreted code in a goroutine would affect ALL goroutines that happen to run some interpreted code. That's not something I consider useful, or even acceptable. If the interpreter did not support goroutines, I could store such debugger information in a global variable, but alas, because of goroutine support, global variables must be excluded. If interpreted functions accepted an extra parameter context.Context, goroutine id or similar, I could pass debugger information in it, but alas that's not the case - for a very strong reason explained above. It seems to me the only possible (and painful) solution is to have thread-local data indexed by a goroutine id, and store in such thread-local data all the per-goroutine debugger information, as for example: * a flag telling whether single-stepping is enabled or not. * the call stack of interpreted functions, to implement a "backtrace" debugger command etc. Suggestions on how to avoid such thread-local data ? Thanks, Massimiliano Ghilardi -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
