chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] egg announcement: remote-repl


From: Elf
Subject: Re: [Chicken-users] egg announcement: remote-repl
Date: Mon, 18 Aug 2008 09:19:45 -0700 (PDT)

On Mon, 18 Aug 2008, Jörg F. Wittenberger wrote:

Hi Elf,

first of all: sorry about not having had the time to read your egg but
anyway asking questions about it.

please read the docs in the future, as this issue is addressed.


Actually having such a facility and not being able to use it as I *want*
to, made me ask for shared parameter objects at the first place in the
other tread over there.

My context: several servers spread across the country talking TCP to
each other.  There are several timeout, counter and other parameters -
within chicken and elsewhere in my program - if I want to set them from
a "remote-repl", which presumably runs in it's own thread (since it
would be otherwise just a demo).


as a sidenote, i cannot think of any legitimate reason to change timeouts
dynamically.

every repl session is in its own thread.  as tcp timeouts are parameters,
if you want to change the timeouts for that particular thread, all you have
to do is:

(rrepl-client-send client-obj '(tcp-read-timeout 50000))

as an example, assuming that client-obj is a client previously defined by
rrepl-client-connect, and that you wanted to set the read timeout to 50000.

it is generally inadvisable to do this, however, in the current implementation
of the remote-repl egg.  first, timeouts need to exist.  second, part of how
the thread-quantum values are set is from the timeouts, to optimise thread flow. the rrepl-server-start procedure takes in optional (keyworded) values for the timeouts, so you can set it sanely upon initial creation of the server, which will propagate to the sessions. third, remote-repl egg handles
the timeouts gracefully, either looping if timeout is reached (in cases like
clients waiting for the return value from a command, since its unknown how
long the evaluation will take) or by yielding their timeslice and restarting
from the top (in cases like waiting for initial input to read, accepting new
connections, etc). in other words, the remote-repl behaves the way you would expect a repl to behave. while completely generalised and completely
configurable, everything is wrapped, so all of the intricate condition
handling and error handling and thread semantics are completely hidden from
the user, and you don't need to worry about it.

-elf

reply via email to

[Prev in Thread] Current Thread [Next in Thread]