ESP32 Forum

select only support lwip now, and i need to wait for queue and sockets together, Is there any good ways?
I try to use loopback socket, but failed to conncet, my thought is shown below:
1, I create a socket bind to "127.0.0.1", and another socket to connect to it, trying to get a couple of sockets like pipe.
2, Then I create a thread handling the sockets(the one communicating with srv and the one described in step 1).
3,I create a thread waiting for queue using xQueueReceive, and notify the socket handling thread with a socket described in step 1.
Hower in step 1, I failed to connect to the local srv "127.0.0.1", then i found http://bbs.esp32.com/viewtopic.php?f=13 ... 6367#p2258
is'nt loopback support now?
is there a bettery way to handle this situation?

Can you elaborate or your use of sockets select()? Are you waiting for incoming network data from outside the ESP32 or are you using the select mechanism for some form of inter-thread signaling exclusively within the ESP32?

kolban wrote:Can you elaborate or your use of sockets select()? Are you waiting for incoming network data from outside the ESP32 or are you using the select mechanism for some form of inter-thread signaling exclusively within the ESP32?

Thanks, I will try to describe more:
1, I want to create a thread handling the communication with srv outside the ESP32, and waiting for queues (when some other threads need to send some data to srv outside the ESP32) inside of ESP32. THIS IS MY REAL PURPOSE!!
2, queues created by xQueueCreate don't have fds to be selected, so I want to use loopback sockets to achieve the goal described in step 1. steps described below:
2.1 a thread handling the communication with srv outside the ESP32, and communication with socket inside ESP32 (using select).
2.2 another thread wating queues, when other threads xQueueSend, this thread will succeed to xQueueReceive, then write info to the socket connected with the socket inside ESP32 described in step 2.1

Thanks for the response. I had a similar need a while back. I had to block waiting on multiple sockets (used select) but also needed to respond to internal events. What I ended up doing was having my main processor block exclusively on a message arriving on a queue. This handled the situation where other tasks could post to the queue and wake up my main task. As for sockets, I had a task that was dedicated to performing a select on a socket and, when it indicated that something needed handling, I then wrote a message into the queue that indicated the file descriptor of the socket that was available to do work.

In your story, I sense you are using sockets for internal wakeups ... in my design, I used queues as the primary communication and translated a socket being ready into a queue event.

kolban wrote:Thanks for the response. I had a similar need a while back. I had to block waiting on multiple sockets (used select) but also needed to respond to internal events. What I ended up doing was having my main processor block exclusively on a message arriving on a queue. This handled the situation where other tasks could post to the queue and wake up my main task. As for sockets, I had a task that was dedicated to performing a select on a socket and, when it indicated that something needed handling, I then wrote a message into the queue that indicated the file descriptor of the socket that was available to do work.

In your story, I sense you are using sockets for internal wakeups ... in my design, I used queues as the primary communication and translated a socket being ready into a queue event.

Nice!!Why didn't I think of that! Thanks a lot! This help me a lot!
Yes, I want to use sockets for internal wakeups.

Now I can use queue to do so:
1, a thread wating for queues including internal events and events that socket available to work.
2, another thread select on sockets, and when socket available, send a message to the queue in step 1.
3, Thread in step 2 doesn't read or write socket at all ,just waiting for socket events. And Thread in Step 1 read and write socket instead!