Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP server hard to use with any locks in handlers and it should be in the documentation #512

Open
mikhail-m1 opened this issue Nov 12, 2024 · 3 comments

Comments

@mikhail-m1
Copy link

I want to bring back #287. I stumbled on it, and I think it has to be mentioned in the documentation and an example of writing HTTP server with state would be ideal.

I have next scenario:

  1. I have an app mutex which protects the app data and list of web socket sessions.
  2. The main thread waits for an event, obtains the mutex, store some data and notify clients by web socket.
  3. On event clients make HTTP query and get the data.
  4. The handler for get data locks and send the data.

Because of the single thread server main thread holding the lock and trying to send which waits for result and the server thread trying to obtain the lock to get access to data.

I think it should work If I split the mutex in two, one for data and one for web socket sessions, and I also use a channel to handle web socket events.

@ivmarkov
Copy link
Collaborator

I'm not sure what else I could add to the topic, besides pointing you to this explanation.

Also, I'm not really sure in the details of your implementation, as it is explained with a few words, rather than with code.
I can only speculate, but it seems you are deadlocking by the virtue of you utilizing a simple blocking mutex rather than a channel or something similar.

Perhaps an easy(er) solution would be to just send the data when you are no longer holding the lock?

I want to bring back #287. I stumbled on it, and I think it has to be mentioned in the documentation and an example of writing HTTP server with state would be ideal.

Yes, that would be ideal. However, if somebody does not do it, it will be never done.
The thing is, the esp-idf-* crates are a community effort, so things to get moving we do need support (in the form of PRs) from the community. I neither work for Espressif, nor am I paid for any time I dedicate for the esp-idf-*crates.

In the meantime, I've moved away from the ESP IDF websockets client/server impls, as they are not really async, and have a lot of restrictions. I am personally actively working on and trying to use edge-http instead.

@mikhail-m1
Copy link
Author

Hey, first of all sorry if my bug report offend you in any way, and thank for all work you done for the community.

I don't mind to make a PR with the documentation changes and another one with example when I manage to create one.

@ivmarkov
Copy link
Collaborator

Sorry if I sound offended - not at all!

But we have to be transparent with the community as to what level of support they could expect in the esp-idf-* crates. Or else we might build wrong expectations.

We may even put some wording in the READMEs that this effort is not sponsored by Espressif soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

2 participants