[erlang-questions] Erlang newbie questions

[OvermindDL1]

I use Erlang with my C++ projects quite well, and I use an escript to
connect to the running node to do things like query for alive status to
things like pulling or pushing data, never needed the pid file as I can
just ask the system for it, plus it changes on occasion.
On Oct 23, 2011 8:58 PM, "Garrett Smith" <g@REDACTED> wrote:

> Hi Sam,
>
> On Sun, Oct 23, 2011 at 7:57 PM, Sam Bobroff <sam@REDACTED> wrote:
> > Hi Garrett & all,
> >
> > About this part:
> >
> >> I use run_erl to run Erlang. This doesn't plug into typical watchdog
> >> apps, which look for pids, but it provides a way to communicate with
> >> Erlang (using to_erl) without using distributed Erlang. I've used this
> >> technique extensively and find it robust.
> >
> > I've also used run_erl and found it less than robust. I'd like to
> > highlight the following issues:
>
> I probably should have been more specific, since we have different
> interpretations of "robust".
>
> run_erl does what it claims to do without bugs (that I've
> encountered). It's an effective controller for Erlang processes that
> can obviate the need for pidfiles or distributed Erlang.
>
> > * You can specify the pipe directory but not the pipe names. This
> > means that if you want to run two or more emulators, you cannot tie
> > the pipe name (which you need in order to connect to the VM) to the
> > emulator. (You can give every one a different directory if you
> > re-write the start script but this seems like a workaround rather than
> > a proper feature and the next issue still causes problems...)
>
> I'm not sure what your critique here is. Surely you're point isn't
> merely that run_erl uses a directory to manage its files.
>
> Take a look at /var/run on any system you have handy -- you'll see
> that lots of applications do this.
>
> For those interested, it's trivial and safe to run multiple beam
> processes, each using run_erl.
>
> > * The pipes aren't cleaned up if the emulator crashes or won't start.
> > Even if you run only a single emulator, it may be running on
> > /tmp/erlang.pipe.1 or /tmp/erlang.pipe.2 or whatever, depending on
> > previous crashes.
>
> This another surprising issue, considering how commonplace it is to
> have orphaned pidfiles hanging around after a process crash.
>
> If you need to cleanup after a crash, just delete the files. If you
> need that automated, automate it.
>
> > * run_erl provides only a single connection. If a program or user
> > already has the pipe open, other connects will hang or fail. A locked
> > up session will therefore prevent you from establishing another
> > session to clean it up -- or to shut down the emulator.
>
> Not only is this not a problem, it's a benefit over pidfiles and
> process signals, which in themselves don't provide any control over
> concurrent access.
>
> And if your session is locked and you need to force your way into it,
> use the -F option of to_erl.
>
> > * run_erl's single session is like a shared terminal: it has a shared
> > input buffer and the state isn't reset or cleared between connections.
> > If you set up a script or program to use it to control an emulator,
> > what happens if someone's session (or a bug in a program) leaves an
> > unfinished command or term in the buffer? (What happens is that all
> > subsequent commands fail, that's what!)
>
> You just said this: "You know what happens when I send garbage to a
> file? I corrupt that file, that's what!"
>
> > * Be careful using run_erl without specifying which pipe to use. It's
> > default is to try each in turn until it gets a connect.
>
> I assume you mean to_erl -- run_erl requires a pipe dir.
>
> to_erl looks in /tmp by default -- I haven't seen it hunt for
> different locations.
>
> In any case, it's a good idea to create a directory explicitly for
> these files and specify it when using to_erl.
>
> > It's easy to see these problems in action. On Ubuntu (and probably on
> > a stock compile as well) try running "/usr/lib/erlang/bin/start" on
> > the command line. Here's what happens on my system for a really
> > trivial example:
> >
> > $ /usr/lib/erlang/bin/start
> > $ echo $?
> > 0
> >
> > So it has started successfully! Yay!
> >
> > $ to_erl
> > No running Erlang on pipe /tmp/erlang.pipe.2: No such device or address
> >
> > Wait, what?
> > Why isn't it running? Why is it erlang.pipe.2 instead of .1?
> >
> > Where are the logs? Nowhere?
> >
> > Of course through experience I know what kind of problems will be
> > happening here but good luck figuring it out if you're new to Erlang.
>
> For those new to Erlang or not, don't do this, or pay any attention to
> this example.
>
> Use run_erl to start the VM, as per the docs:
>
> http://www.erlang.org/doc/man/run_erl.html
>
> And use to_erl to connect to that process. You'll need to specify the
> pipe dir so to_erl knows what you want to talk to.
>
> > For fun try setting up an init script that uses to_erl to control an
> > emulator. Then do this:
> >
> >  echo x > /tmp/erlang.pipe.1.w
> >
> > And then try to use your script.
>
> Also, don't kill -9 processes that you want to keep running.
>
> > Peace,
> > Sam.
> >
> > P.S. I still love Erlang. I'm just sayin' it "for the record" as Joe
> suggests.
> >
>
> Word
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111024/434006e6/attachment.htm>