search

frenetic-lang / frenetic

The Frenetic Programming Language and Runtime System
http://www.frenetic-lang.org/
Other
223 stars 51 forks source link

Better Heuristic For Finding Openflow Executable #508

Open craig-riecke opened 8 years ago

craig-riecke commented 8 years ago

When Frenetic runs with http-controller, it starts up the separate executable openflow.native as a subprocess. This works fine for programming in Python or REST. However, it doesn't work well when building a monolithic OCaml Frenetic app (basically the Northbound app is compiled in with Frenetic itself).

Currently the workaround is to create a symbolic link to openflow.native in the same directory as the monolithic app executable, as show in the Wiki. It'd be nice not to require that.

smolkaj commented 8 years ago

Just compile with make install. Then openflow should be on the PATH.

craig-riecke commented 8 years ago

Yeah, that would work ... if a monolithic app looked on the PATH. It doesn't. It only looks for openflow or openflow.native in the same directory as the executable you're running. The logic is in Frenetic_OpenFlow0x01_Controller.ml line 30.

It should be an easy fix.

jnfoster commented 8 years ago

Wait. Why do we have two executables anyway? It seems like it only causes confusion with PATH, etc. I think we should run frenetic.native twice (or n times) with different command-line arguments -- once for the high-level controller and once for the low-level controller. The first one could even fork() to create the other copies so we only need one invocation at the command line.

-N

On Tue, Jun 21, 2016 at 3:03 PM, Craig Riecke notifications@github.com wrote:

Yeah, that would work ... if a monolithic app looked on the PATH. It doesn't. It only looks for openflow or openflow.native in the same directory as the executable you're running. The logic is in Frenetic_OpenFlow0x01_Controller.ml line 30.

It should be an easy fix.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/frenetic-lang/frenetic/issues/508#issuecomment-227539142, or mute the thread https://github.com/notifications/unsubscribe/ABwi0gzfkXPGqw5W4reJteIBYXDfm3z8ks5qODV-gaJpZM4I6sgQ .

craig-riecke commented 8 years ago

@jnfoster We do use one invocation - the frenetic.native binary (or the monolithic app) starts the openflow.native binary through Process.create. It would be great to use fork instead, but we can't because of Async. Or rather, the Async scheduler - we start it up to handle some deferred's and ivar's (they are needed for other parts of Frenetic) prior to creating the openflow.native process. If we forked, the Async scheduler would be totally mucked up in the child process, ref: https://groups.google.com/forum/#!topic/ocaml-core/an6dwjN_yCY

We could do one binary, but a monolithic app would have the same problem finding frenetic.native - Process.create doesn't look through the PATH by default. Unless maybe it started another copy of itself...

smolkaj commented 8 years ago

good point...

jnfoster commented 8 years ago

Not sure which point is a good one.

It would still be my preference to have a single binary -- it eliminates complexity in several places.

-N

On Wed, Jun 22, 2016 at 1:53 PM, Steffen Smolka notifications@github.com wrote:

good point...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/frenetic-lang/frenetic/issues/508#issuecomment-227824334, or mute the thread https://github.com/notifications/unsubscribe/ABwi0jFm3fmulD6ULWn7rr9KTLY0sEq7ks5qOXZ_gaJpZM4I6sgQ .

smolkaj commented 8 years ago

"Good point" was referring to Nate's comment. Having two binaries trying to find each other sounds like it will break very easily. There must be a way around it.

Craig, under the link you posted they mention reset_in_forked_process. Can't we use that?