Joe Holloway wrote: > On Wed, Jun 23, 2010 at 7:23 PM, Stuart Halloway <[email protected]> > wrote: >> If the context represents any real resources on the native side, I would >> recommend going in the opposite direction: >> >> (1) Clients should create and hold the context, and explicitly close it when >> they are done. >> >> (2) Ditto for sockets (except that creation is via the context). >> >> (3) Neither Context nor Socket should implement finalize. >> >> (4) Instead, they should implement the Closeable interface [1]. >> >> How costly is the context? Should it be created once per process? Once per >> thread? Something else?
Once per "application" the application being either executable or an library. The aim of the context is to prevent mis-interactions when two libraries, each using 0mq, are loaded into the same process. Context for example holds a list of inproc endpoints, so if library A creates inproc endpoint X and library B happens to create X as well, it will work without two messing with each other. >> [1] http://java.sun.com/j2se/1.5.0/docs/api/java/io/Closeable.html In overall, language binding should make it as easy for the users as possible to use the bindings. If Java people here feel that the above would achieve the goal, then yes, it should be implemented that way. > I can't speak to how expensive these resources are (or could be in the > future), but will add +1 for these suggestions. I had a similar > thought back when I was working with the 2.0.5+ version of the API, > but the Java binding underwent a hefty design phase to make it > look/feel more like some of the other language bindings. > > Now that you've brought it up again, it makes me wonder if there ought > to be a general guideline in the binding developer guidelines [1] to > implement support for a given language's "resource closing" interface > (whatever analogy exists in the given language). For example, Java > has java.io.Closeable, Python has the "context management protocol" > for use in "with" statements, etc. > > [1] http://www.zeromq.org/guidelines:bindings Feel free to propose the language... Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
