1 Reply Latest reply on Nov 5, 2018 12:06 AM by ZhengbaoZ_96

    http_client : can http_request ever be allocated on the stack?

    DaMo_2831246

      I'm using http_client for long term communications with my backend. Is it possible to use a local variable of type http_request_t (and have it be allocated on the stack), or must all http_request_t variables be declared static (and permanently consume memory)?

       

      One issue with local http_request_t variables is that you must call http_request_deinit() after the request has completed, to clean up various resources. But the call to http_request_deinit() sends an asynchronous event to another thread (request->owner->thread) to perform some of the cleanup, and passes the http_request_t as a message parameter. If the http_request_t is allocated on your stack, and goes out of scope before the asynchronous cleanup is completed in the http_client's work thread, you run the very real risk of overwriting the http_request_t before the cleanup is complete, or of having that subsequent cleanup corrupt your stack.

       

      If you do have a statically declared http_request_t, how do you know when it's safe to reuse that http_request_t? Again, calling http_request_deinit() invokes an asnchronous request to another thread, which is dependent on the initial state of the http_request_t -- you can't reuse the http_request_t until that cleanup is complete, but you don't know when that's true.

       

      Thanks for any insights.

       

      Dave

        • 1. Re: http_client : can http_request ever be allocated on the stack?
          ZhengbaoZ_96

          Hello:

           

          Actually,  from the code it is using global way to define a http_request_t.

          I found http_request_t init and delete is in the same function like sensors_http_post in our demo.

          and I guess your concern is  http_request_deinit() is not finished in another thread before a new https_post request is coming,  is that right ?  If really care about this, I think we can have a try to add flags before the http_request_init.    if deinit is on-going , we can add a small waiting to check the flag again.

          1 of 1 people found this helpful