Bram Peeters wrote:
Solutions I see:
[1] In LWIP_NETCONN_THREAD_SEM_ALLOC do an extra malloc of a pointer
variable besides creating the semaphore, fill in the handle of the
semaphore in that pointer variable and return the address of the
pointer variable in LWIP_NETCONN_THREAD_SEM_GET
That's what the windows port does. You don't have to malloc() the
pointer though...
[2] Expose the real semaphore type from freertos and typedef that to
sys_sem_t (instead of the handle/pointer type).
That doesn't work if the OS headers are C++
[3] Replace the sys_sem_t type in lwip by a sys_sem_handle_type.
Stuff below (sockets.c) gives me the impression that this would make
things much cleaner
That would be an idea. I'm open for patches implementing this ;-)
[4] ... ?
4: Extend the OSes thread structure by a semaphore object. That way,
_ALLOC() does nothing and _GET() just returns a pointer to this object.
This only works if you have the thread at your hands, of course. You can
also allocate the object beside the stack when creating the thread with
sys_thread_new()...
TLDR: choice for 'direct' semaphore type in lwip seems to lead to
messy workarounds because not all OS'es support direct semaphore types....
That's why it isn't implemented like that.
Simon
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
