I use C++ and prefer to use a task class that I designed. I do not want to
allocate these statically. It's not clear to me why the network stack would
be concerned with creating threads. I understand that there is a network
thread that is created but I don't want it created by sys_thread_new.
As f
There may be other parts of the code that create threads, depending on how
you use them - e.g. SNMP supports netconn mode which creates a thread.
But you don't need to avoid sys_thread_new - just implement this function
so it uses your own class to create a thread.
Dirk
On Sun, Oct 9, 2016 at 7:
On nie, 2016-10-09 at 05:08 +, Kenny Koller wrote:
> I use C++ and prefer to use a task class that I designed. I do not
> want to allocate these statically. It's not clear to me why the
> network stack would be concerned with creating threads. I understand
> that there is a network thread that
> but in practice how would be be used? It seems that you still need to
> preallocate a number of mailboxes or semaphores. Is creating a simple
> static array in sys_arch.c and doing some book keeping on which have been
> allocated/freed a reasonable approach?
>
> Regards,
>
> K
On nie, 2016-10-09 at 18:36 +, Kenny Koller wrote:
> It seems that the conservative thing to do is use the heap to get
> started and as I become comfortable with the code base I'll consider
> what is required for static allocation. I'll also just let LWIP
> create it's own tasks using the C API
>
>
> I still don't understand the statement I quoted from the documentation.
> For example how would one allocate on the stack for sys_mbox_new()?
>
You can't. All you can do in such cases is count how many
mboxes/semaphores/threads etc. you need and allocate their storage
statically. A call to
On pon, 2016-10-10 at 08:58 +0200, Dirk Ziegelmeier wrote:
> You can't. All you can do in such cases is count how many
> mboxes/semaphores/threads etc. you need and allocate their storage
> statically. A call to sys_mbox_new() just returns "the next one" from
> the static allocated ones. This is wh
You are right, this will also work.
Even in lwIP 1.4.1 the prototype for these functions was:
> err_t sys_sem_new(sys_sem_t *sem, u8_t count);
> err_t sys_mbox_new(sys_mbox_t *mbox, int size);
>
> These functions clearly don't return anything else other than error and
> the buffer for semaphore/m