lwIP - A Lightweight TCP/IP stack - Patches: patch #5960, Enable multithread send/recv...
You are not allowed to post comments on this tracker with your current authentication level.
patch #5960: Enable multithread send/recv operations on same socket on TCP netconns
Submitter: | Frédéric Bernon <fbernon> | ||
Submitted: | Wed 23 May 2007 10:44:53 AM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Wont Do | Privacy: | Public |
Assigned to: | fbernon | Open/Closed: | Closed |
Planned Release: | None |
Jump to the original submission
Mon 30 Nov 2009 11:31:53 PM UTC, comment #41: |
Mike <mikeredd> |
Sat 09 Jun 2007 11:10:27 AM UTC, comment #40: Because LWIP_TCPIP_CORE_LOCKING option is already a partial solution to fix this problem, and because it seems I'm the only active developer using full-duplex protocols, I close that (but it should be one of the goal of a new socket layer)...
|
Frédéric Bernon <fbernon> |
Tue 29 May 2007 01:11:55 PM UTC, comment #39: About comment #36, of course, I can (I have some others differences with current CVS I don't check in). But I don't share your point of view that is "a partial solution to a rare problem" : full duplex protocols are pretty common (perhaps only in my domain of activity?), and I thought it could help some others users... But ok if you prefer to don't check in that...
|
Frédéric Bernon <fbernon> |
Tue 29 May 2007 12:58:18 PM UTC, comment #38: OK, now I understand you ;-)
|
Simon Goldschmidt <goldsimon> |
Tue 29 May 2007 12:55:36 PM UTC, comment #37: Some answers are in comment #31:
"in "tcpip.c", lock the connection to protect concurrent access in "tcpip_apimsg()", adding a sys_sem_wait(apimsg->msg.conn->apisem) and a sys_sem_signal(apimsg->msg.conn->apisem)."
in netconn_new_with_proto_and_callback(), if LWIP_API_MULTITHREAD_PROT=1
it's one per connection(netconn), but I don't understand "would be the same as what we have now"? Which one? "sys_sem_t sem;" in "struct netconn"? It it's this one, it is not used for that (I suppose it's mainly used in "write" and "close" to avoid to consumne cycles to check a state).
|
Frédéric Bernon <fbernon> |
Tue 29 May 2007 12:49:45 PM UTC, comment #36: From the sound of it it's a pretty small change. Would it be possible for you to keep this in your own tree for the time being? I know CVS doesn't make that easy, but this seems to be a partial solution to a rare problem, and so I'm not convinced it should be checked in yet.
|
Kieran Mansley <kieranm> |
Tue 29 May 2007 12:48:31 PM UTC, comment #35: - Where would you add the sys_sem_signal(apimsg->msg.conn->apisem)?
|
Simon Goldschmidt <goldsimon> |
Tue 29 May 2007 12:36:07 PM UTC, comment #34: About comment #32, I think there is no risk with a patch like this, even for netconn_write (where the problem is more on the RX side, with the "tcp_sndbuf", but here, only one thread write). The main problem is to avoid that task1 fetch a msg posted in answer of an action to task2. Note unlike you said, it will not "protect the core stack", but only the connection (the apisem is only in struct netconn).
|
Frédéric Bernon <fbernon> |
Tue 29 May 2007 12:17:58 PM UTC, comment #33: Couldn't we leave that limitation (only use the sockets from one thread) in the current socket layer if we develop a new one?
|
Simon Goldschmidt <goldsimon> |
Tue 29 May 2007 09:17:26 AM UTC, comment #32: Does this really solve the problem? I can see that it is going to protect the core stack, but is there no state in the upper layers (netconn, sockets) that will also require protection?
|
Kieran Mansley <kieranm> |
Sat 26 May 2007 12:53:40 PM UTC, comment #31: So, to fix the problem "one thread read, another one write on a tcp connection" to support full duplex on a TCP connection, I propose the solution:
|
Frédéric Bernon <fbernon> |
Thu 24 May 2007 12:34:33 PM UTC, comment #30: I think this task should stay open, for the "one thread read, another one write on a tcp connection". Just a sample for that: a remote serial port (like moxa products). And any other full duplex protocol.
|
Frédéric Bernon <fbernon> |
Thu 24 May 2007 12:12:30 PM UTC, comment #29: I've already opened task #1549 (prio later) for that discussion.
|
Simon Goldschmidt <goldsimon> |
Thu 24 May 2007 12:09:13 PM UTC, comment #28: Lots of separate issues being discussed here, but here is my thoughts on the big ones:
|
Kieran Mansley <kieranm> |
Thu 24 May 2007 10:43:03 AM UTC, comment #27:
|
Simon Goldschmidt <goldsimon> |
Thu 24 May 2007 10:34:53 AM UTC, comment #26: About recv/close scenario, I don't think it's something really important, some OS propose it, but most of time, only to close a service running.
|
Frédéric Bernon <fbernon> |
Thu 24 May 2007 07:57:03 AM UTC, comment #25:
|
Atte Kojo <kojo> |
Thu 24 May 2007 07:13:05 AM UTC, comment #24: re comment #23:
That would help much, since it would eliminate many OS calls (apart from mutexes). But here again, semaphores would be a bad idea, mutexes would be much better!
|
Simon Goldschmidt <goldsimon> |
Thu 24 May 2007 06:24:07 AM UTC, comment #23: If I've understood correctly there are actually two multithread issues here.
|
Atte Kojo <kojo> |
Thu 24 May 2007 12:17:50 AM UTC, comment #22: Re comment #15:
|
Jonathan Larmour <jifl> |
Wed 23 May 2007 08:07:24 PM UTC, comment #21: Misusing a field ? ;) To study, but if we replace the "sys_mbox_t mbox;" by a "sys_sem_t* apisem", the size won't change (from actual code, of course).
|
Frédéric Bernon <fbernon> |
Wed 23 May 2007 07:53:49 PM UTC, comment #20: Ah, OK, you're right, I missed that. Can't we somehow reuse the acceptmbox for that? That way, the struct netconn wouldn't grow, and accept and connect can't be called on the same netconn anyway. |
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 06:29:31 PM UTC, comment #19: Umm, I think I have understand, but there is always the problem for "connect". For all others, you could have something like :
|
Frédéric Bernon <fbernon> |
Wed 23 May 2007 06:21:23 PM UTC, comment #18:
|
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 04:22:11 PM UTC, comment #17:
It could be good, but there is ONE case where it's necessary to let it at inside "netconn" struct: the connect !!!
|
Frédéric Bernon <fbernon> |
Wed 23 May 2007 04:11:26 PM UTC, comment #16:
|
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 02:48:24 PM UTC, comment #15:
|
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 02:47:05 PM UTC, comment #14: prio can be use like an ID if you never have two tasks with the same prio value. In my OS, sys_get_current_task() return a value inside [0...MAX_TASK-1], and it's good for me..
|
Frédéric Bernon <fbernon> |
Wed 23 May 2007 02:43:18 PM UTC, comment #13: Re timeouts: sort of, yes. But it's a pain if you don't have real per-thread data. Instead you have to have a table with entries for each thread, and look it up each time (and this is even worse if threads can be deleted). Anyway, this is a side issue - more important is whether a per-thread sem can even work anyway.
|
Jonathan Larmour <jifl> |
Wed 23 May 2007 02:40:41 PM UTC, comment #12:
|
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 02:36:33 PM UTC, comment #11:
|
Frédéric Bernon <fbernon> |
Wed 23 May 2007 02:24:00 PM UTC, comment #10:
|
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 02:14:35 PM UTC, comment #9:
|
Frédéric Bernon <fbernon> |
Wed 23 May 2007 02:06:31 PM UTC, comment #8:
|
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 02:01:13 PM UTC, comment #7: Yes, eCos for example has this issue - mboxes are a fixed size. Even for variable size queues, ultimately it can fail - memory has to come from somewhere!
|
Jonathan Larmour <jifl> |
Wed 23 May 2007 01:33:22 PM UTC, comment #6: Yes, it's a thing to do (once we will use a semaphore instead of conn->mbox), but I think in another task... |
Frédéric Bernon <fbernon> |
Wed 23 May 2007 01:24:21 PM UTC, comment #5: Introducing a return value to shown the message wasn't posted would prevent tcpip_thread from blocking, the datagram would simply not be received. |
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 01:19:52 PM UTC, comment #4: Yes, ASSERT can be used to signal that the size used is to small and that we have fill the queue, but it's just good at development time. Take the current code and this situation:
|
Frédéric Bernon <fbernon> |
Wed 23 May 2007 12:57:26 PM UTC, comment #3:
|
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 12:39:56 PM UTC, comment #2:
|
Frédéric Bernon <fbernon> |
Wed 23 May 2007 11:13:20 AM UTC, comment #1:
|
Simon Goldschmidt <goldsimon> |
Wed 23 May 2007 10:44:53 AM UTC, original submission:
Currently, with UDP connections, you can sendto and recvfrom datagrams with two threads (one read, the other write). You can't do two reads in the same times, but it's not a usual case. You could do two sends in the same time, but there is a problem with current tcpip_thread api, because the tcpip_thread can't know which task will fetch the message (and will be wake up). More, about TCP, it's not possible to have a thread who read and another who write (to implement full duplex protocols)...
|
Frédéric Bernon <fbernon> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-06-09 | fbernon | Status | None | Wont Do | |
Assigned to | None | fbernon | |||
Open/Closed | Open | Closed |
Powered by Savane 3.13-4448.
Corresponding source code
Had you done this, you would have saved me a lot of time!
Let me add a vote for full duplex support... I assumed it would work and felt it was a bug when it didn't. (It seemed to work, but with a rare and difficult to diagnose problem. This made lwip seem unstable.)
We have one thread waiting for data from a controller, plus an occasional need to notified the controller of and event. So with one thread blocked on netconn_recv(), how can we send on the same connection?