Hi Jonathan,
Good point !! Now I remember that something was very strange to me
regarding this semaphore. Well, to be sure I have to check with the
debugger but for now I can only comment what could be happening inside.
I'll try to describe it:
1) netconn_new_with_proto_and_callback() creates the semaphore and the
semaphore is initialized to 0. After that tcpip_apimsg() is invoked
which sends the do_newconn() function to the main tcp thread. The
tcpip_apimsg() function pends on the op_completed semaphore with 0 time.
2) Depending on the task priorities the tcpip_apimsg() function might
return immediately with ERR_OK. When the main tcp thread completes the
do_newconn() function the op_semaphore is posted and after that it has
the value of 1.
3) When then I call netconn_connect() the semaphore is already posted,
thus returning immediately with ERR_OK.
This is what I can reduce from observing the code. It seems like a race
condition which is depends on task priorities. Please don't get me wrong
- I have to check this with the debugger.
marko
Jonathan Larmour wrote:
Marko Panger wrote:
Hi again,
I'm still unable to reproduce the proper behavior or the behavior as
Frédéric described below. The point is still that netconn_connect()
returns ERR_OK even if there is nobody listening on the other side.
What happens behind the scenes is that a message will get posted to
the tcpip thread's mailbox, and the calling thread should wait on a
per-connection semaphore (called op_completed) for the tcpip thread to
indicate that the operation has completed.
Perhaps somehow that semaphore did not have the correct state before
the call - perhaps it had already been signaled? Or had not been
created in the port with a value of 0 - in netconn_alloc() in
api_msg.c, lwIP requests it to be created with a value of 0, but
perhaps something doesn't do it right in the port?
Jifl
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
