Linas Vepstas <linasveps...@gmail.com> skribis: > On Mon, Sep 11, 2017 at 2:26 AM, Ludovic Courtès <l...@gnu.org> wrote: > >> Hello, >> >> Linas Vepstas <linasveps...@gmail.com> skribis: >> >> > The stuff coming over the network sockets are bytes, not s-exps. Since >> none >> > of the bytes are ever zero, they are effectively C/C++ strings, and are >> > handled as such. These C strings are sent to scm_eval_string() wrapped >> > by scm_c_catch(). >> >> I don’t know to what extent that is applicable to your software, but my >> recommendation would be to treat that network socket as a Scheme port, >> pass it to ‘read’, and pass the result to ‘eval’ (as opposed to reading >> the whole string from C++ and passing it to ‘scm_eval_string’.) >> > > Why? What advantage does this offer?
It avoids copies and conversions, which is big deal if you deal with very big strings. > Its not clear that guile eval is smart enough to manage a network socket -- > if the user starts a long-running process with intermittent prints, will it > send that to the socket? What if the user hits cntrl-C in the middle of it > all? What if the code that came over the socket happened to throw an > exception? These are important considerations, but it’s not eval’s business IMO. Instead, I suggest building your own protocol around it, and having a way in that protocol to report both exceptions and normal returns. > I've had to deal with all of these issues in the past, and have a stable > code base; but if I had to start all over again, its not clear that these > issues have gone away. I mean, eval was designed to eval -- it was not > designed to support multi-threaded, concurrent network operations, right? Right. > To support my point: the default guile network REPL server is painfully > slow, and frequently crashes/hangs. It works well enough to do some demos > but is not stable enough for production use ... if its just read+eval, that > might explain why its unstable. I’ve never noticed slowness of the REPL server, nor crashes. That said, if you run a REPL server in a separate thread and mutate the global state of the program, you could possibly crash it—no wonders here. Likewise, the REPL server is meant to be used for debugging on localhost. If you talk to a REPL server over the network with high latency, it’s going to be slow, not surprisingly. So yes, I find the REPL server to be a really pleasant tool when debugging an application locally, but that’s all it is—it’s not a remote procedure call framework or anything like that. Thanks, Ludo’.
