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? 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? 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? 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. --linas -- *"The problem is not that artificial intelligence will get too smart and take over the world," computer scientist Pedro Domingos writes, "the problem is that it's too stupid and already has." *
