Re: Guile bugs

[ludo@gnu.org (Ludovic Courtès)]

Linas Vepstas <linasvepstas@gmail.com> skribis:

> On Mon, Sep 11, 2017 at 2:26 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Hello,
>>
>> Linas Vepstas <linasvepstas@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’.