http_client : can http_request ever be allocated on the stack?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
DaMo_2831246
Level 3
Level 3
First like received First like given

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 Solution
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

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.

View solution in original post

1 Reply
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

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.