lwIP - A Lightweight TCP/IP stack - Patches: patch #6723, Add option UDP_EXT_RECV_CALLBACK...
You are not allowed to post comments on this tracker with your current authentication level.
patch #6723: Add option UDP_EXT_RECV_CALLBACK to enable new API function udp_ext_recv()
Submitter: | Jakob Stoklund Olesen <stoklund> | ||
Submitted: | Wed 14 Jan 2009 11:46:32 AM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Done | Privacy: | Public |
Assigned to: | goldsimon | Open/Closed: | Closed |
Planned Release: | 1.4.0 |
Jump to the original submission
Tue 05 May 2009 06:41:25 PM UTC, comment #13: |
Jakob Stoklund Olesen <stoklund> |
Tue 05 May 2009 05:51:19 PM UTC, comment #12: Done by adding 2 new functions:
|
Simon Goldschmidt <goldsimon> |
Tue 05 May 2009 05:46:16 PM UTC, comment #11: I had another thought about this: the parameter pcb does of course make no sense, because ip_input does not know any pcbs. We could leave away the parameter altogether, but that would make it difficult to receive in multiple threads in the future (a thing I still have in the back of my head: being able to prioritize one connection over another, splitted by the hardware or the driver into multiple input queues).
|
Simon Goldschmidt <goldsimon> |
Tue 05 May 2009 08:16:52 AM UTC, comment #10: Yes, looks OK to me. |
Kieran Mansley <kieranm> |
Mon 04 May 2009 06:51:44 PM UTC, comment #9: Just like I thought to implement it. I would just like to get a comment about the 'new' solution from Kieran and/or Jifl, since they took quite a big part in the discussion leading to the initial post. |
Simon Goldschmidt <goldsimon> |
Mon 04 May 2009 07:51:24 AM UTC, comment #8: OK, I have attached a new patch that implements Simon's idea. It works well enough for my purposes, so I think we should go that way.
|
Jakob Stoklund Olesen <stoklund> |
Sun 03 May 2009 10:36:14 AM UTC, comment #7:
|
Simon Goldschmidt <goldsimon> |
Sun 03 May 2009 10:20:08 AM UTC, comment #6: So something like this:
Would you like me to submit a new patch? I think I can find the time to test it Monday.
|
Jakob Stoklund Olesen <stoklund> |
Sun 03 May 2009 10:09:18 AM UTC, comment #5:
|
Simon Goldschmidt <goldsimon> |
Sun 03 May 2009 07:49:43 AM UTC, comment #4: Fine by me - except you loose the opportunity to use these functions in raw and tcp callbacks. The interface could be used for TCP access control, for instance.
|
Jakob Stoklund Olesen <stoklund> |
Sun 03 May 2009 07:31:28 AM UTC, comment #3: I'd give the pcb as an argument though: that way, we are free to move the current-header and current-netif into the pcb, later, if we want that, instead of being tied to saving it global. |
Simon Goldschmidt <goldsimon> |
Sun 03 May 2009 06:27:40 AM UTC, comment #2: How about doing this at the IP level? Then raw PCBs can also benefit.
|
Jakob Stoklund Olesen <stoklund> |
Sat 02 May 2009 09:02:09 PM UTC, comment #1: Just a thought on that: wouldn't it be more backwards-compatible and maybe cleaner (because of having less options) if we implemented a function that received the additional parameters for the pcb?
|
Simon Goldschmidt <goldsimon> |
Wed 14 Jan 2009 11:46:32 AM UTC, original submission:
A UDP pcb can have either an extended or a normal receive callback,
|
Jakob Stoklund Olesen <stoklund> |
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 6 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2009-05-05 | goldsimon | Status | None | Done | |
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed | |||
2009-05-04 | stoklund | Attached File | - | Added ip-callback-info.patch, #18081 | |
2009-04-03 | kieranm | Planned Release | None | 1.4.0 | |
2009-01-14 | stoklund | Attached File | - | Added udp-extend-callback, #17256 |
Powered by Savane 3.13-4448.
Corresponding source code
Thank you, Simon. I agree with your thoughts regarding multithreading and TLS.