- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Tags:
- http_client library
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.