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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to