Re: [lwip-users] LWIP_NETCONN_SEM_PER_THREAD => sys_sem_t type problems

[address@hidden]

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