An update.
First, I can get rid of the handshake now and still at least detect a
"crashing" exec.
Second, I noticed that the current proxy actually tries to flush first stdout
and then stderr and emits the marker separately for stdout and stderr. So, the
idea that both stdout and stderr are to be used for logs is somewhat baked in.
Since I had some problems in synchronising stdout and stderr and the markers (I
solved in a way I feel a bit hackish) I plan to move output to file descriptor
3 also for Go actions, if I am not advised differently.
--
Michele Sciabarra
openwh...@sciabarra.com
On Fri, Mar 9, 2018, at 10:15 PM, Carlos Santana wrote:
> +1
>
> Not just but I think a lot kind of languages will benefit c++, rust, we can
> even use it to migrate with little effort bash and perl all them relying on
> the foundation of new lean and mean go proxy :-)
>
> —Carlos
> On Fri, Mar 9, 2018 at 2:03 PM Michele Sciabarra
> wrote:
>
> > I am loyal to the classical apache way, where everything was happening on
> > the ML, so even if the discussion was sorted out in Slack, I drop an email
> > here to let everyone else to know what is happening.
> >
> > Basically, there is a "secret plan" to conquer the world... well to make
> > Swift actions (that are pretty important) faster.
> > And also another one to implement streaming, but this is another story.
> > So I will have to make the go runtime compatible to allow for those
> > expansions.
> >
> > In short, while by default Go logs in stderr, Swift by default logs in
> > stdout... and it will mess out the "conversation" with the pipe. To avoid
> > this problem, I will have to write the answer on another channel, leaving
> > stdout AND stderr for log... because Go logs by default on stderr, and
> > Swift logs by default in stdout ...
> >
> > Another problem is the handshake. Well it is not really a problem except
> > ... the current implementation of init is lazy and does not do many checks.
> > They rely on the timeout to get rid of misbehaving actions.
> >
> > In conclusion I am going to change the Go runtime this way:
> >
> > - accept more or less any stuff the user sends
> > - detect more errors at /run-time
> > - write output in (ouch!) channel 3 (argh!) to prepare to support Swift
> > - rely in timeout (that force a kill of the runtime) for cleaning the mess
> > (a.k.a.: if I spill on the floor I will wait for the cleaning woman)
> >
> > Guys, did I miss something?
> >
> > --
> > Michele Sciabarra
> > openwh...@sciabarra.com
> >
