FAQ
Here's an implementation for "goroutine local storage":

https://github.com/easeway/gls

The approach is a little tricky and hacking, but it solves my problem :-)

Comments are welcome.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Edward Muller at Feb 27, 2016 at 6:04 am
    https://blog.golang.org/context <https://blog.golang.org/context> ?
    On Feb 25, 2016, at 10:40 PM, easeway@gmail.com wrote:

    Here's an implementation for "goroutine local storage":

    https://github.com/easeway/gls

    The approach is a little tricky and hacking, but it solves my problem :-)

    Comments are welcome.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Easeway at Feb 29, 2016 at 6:23 pm
    golang.org/x/net/context doesn't overlap with gls. Without gls, we have to
    pass context all ways down to every function (that mean every function must
    have an argument of context, this is sometimes difficult if some middleware
    is used, and it's not aware of context). With gls, it's not necessary to
    put context in argument list of functions. It can be retrieved at any time.
    On Friday, February 26, 2016 at 10:04:30 PM UTC-8, freeformz wrote:

    https://blog.golang.org/context ?

    On Feb 25, 2016, at 10:40 PM, eas...@gmail.com <javascript:> wrote:

    Here's an implementation for "goroutine local storage":

    https://github.com/easeway/gls

    The approach is a little tricky and hacking, but it solves my problem :-)

    Comments are welcome.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Roger peppe at Mar 1, 2016 at 9:05 am
    Or just have a global mutexed map[*http.Request]*Context
    and avoid the arcane brokenness.

    On 26 February 2016 at 06:40, wrote:
    Here's an implementation for "goroutine local storage":

    https://github.com/easeway/gls

    The approach is a little tricky and hacking, but it solves my problem :-)

    Comments are welcome.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Easeway at Mar 1, 2016 at 5:48 pm
    The problem is with some middleware, in the handler, we lost the
    information about *http.Request.
    Here's an example, we need to register our own handler to a middleware:

    ```
    middleware.MyRequestHandler = func() bool {
         // do something
         return false
    }
    ```

    The middleware is working by generating some code from some rest
    definition. The generated code hides all details about transportation, and
    the application can focus on the business logic. So we can see from above,
    there's no *http.Request in the callback. If we want to retrieve something
    from http headers, how to do that?

    Fortunately, the middleware allows the application to hook a function
    before it handles the http request, that why gls comes, and creates a
    context at that point:

    ```
    middleware.BuildHttpHandler = func(handler http.Handler) {
         return func(w http.ResponseWriter, req *http.Request) {
            gls.With(createContext(req), func() {
                handler(w, req)
            })
         }
    }

    middleware.MyRequestHandler = func() bool {
         ctx := gls.Get().(*MyContext)
         ctx.Request ...
         // do something
         return false
    }
    ```
    On Tuesday, March 1, 2016 at 1:06:25 AM UTC-8, rog wrote:

    Or just have a global mutexed map[*http.Request]*Context
    and avoid the arcane brokenness.

    On 26 February 2016 at 06:40, <eas...@gmail.com <javascript:>> wrote:
    Here's an implementation for "goroutine local storage":

    https://github.com/easeway/gls

    The approach is a little tricky and hacking, but it solves my problem :-)
    Comments are welcome.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Konstantin Khomoutov at Mar 1, 2016 at 6:05 pm

    On Tue, 1 Mar 2016 09:48:46 -0800 (PST) easeway@gmail.com wrote: [...]
    The middleware is working by generating some code from some rest
    definition. The generated code hides all details about
    transportation, and the application can focus on the business logic. [...]
    Fortunately, the middleware allows the application to hook a function
    before it handles the http request, that why gls comes, and creates a
    context at that point:
    ^^^ This. First, some magic is instilled on the middleware library's
    clients by "hiding from them all details about transportation", and then
    way more magic is used to give those details back.

    So, please fix the middlewhare library or simply throw it away as
    writing middleware libraries for web app backends appears to be a common
    sport for newfangled gophers, and so there really is no shortage of this
    stuff.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 26, '16 at 1:34p
activeMar 1, '16 at 6:05p
posts6
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase