On Tuesday, August 29, 2017 at 10:42:31 AM UTC-7, Tony Garnock-Jones wrote: > It'd also be great for Racket in general to have better visibility into > running programs to see what's going wrong with them in situations like > this.
I think it's possible to do this with existing features and libraries. You could use a thread group[1] to make two sets of threads: one for normal user requests, and one for debugging and introspection requests from administrators. Then, if somehow the request threads got locked up on some CPU-bound infinite loop you could still handle debugging requests. A good debugging endpoint might be one that uses a statistical profiler[2] to get a sense of what the user request threads are doing. A package that provided some convenience wrappers around thread groups, the statistical profiler, and the web server library to automatically make such a debugging endpoint would be a good project for any web-oriented Racketeers out there. [1] http://docs.racket-lang.org/reference/threadgroups.html [2] http://docs.racket-lang.org/profile -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
