lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] upgrading to 1.4.0


From: Walter Saegesser
Subject: Re: [lwip-users] upgrading to 1.4.0
Date: Fri, 24 Jun 2011 07:31:11 +0200

Hi Martin

> 1) Remove all stuff around timers, these are now completely handled
inside LWIP.
> 
> 2) Change function prototypes and implementation around semaphores,
mboxes,etc.
> 
> 3) Add new functions to support mutexes and typedef __type__
sys_mutex_t
> 
> 4) Add new functions to determine if sem/mbox/mutex is valid or to
invalide it.
> Here I would like to ask, what is good *_invalide() for. If this
> functions is called, should I also free the sem/msg/mutex? I could
> understand the *_invalide() is called if and only if during an
> initialization process to set variables into a known state or after
> freeing by *_free().

1) to 3): right.

4) I had problems understanding the "set_invalid" concept, too. Thus I
send you the answer I got from Simon Goldschmidt (25.05.2011), which
gives you some hints about what the intention was. Note that the
direction of the parameters of the set_xxx_invalid functions is OUT and
not IN.

---
The macro sys_mbox_set_invalid() is (like the name says) supposed to set
a pointer to an mbox to a known state so that we can later check if that
pointer is valid (mbox created) or invalid (mbox not created).

E.g. if you defined sys_mbox_t to "void*", then you would

#define sys_mbox_set_invalid(mbox) (*mbox = NULL) [or an appropriate
function, Walter]

since in that define, mbox would have the type "void**".

It has been changed like that because the previous implementation had
the limitation that sys_mbox_t and sys_sem_t always had to be pointers:
we had no way to "invalidate" them when using aggregated OS elements
(since assigning a value - like NULL - does not work then).

So now you might define sys_mbox_t to "struct your_os_mbox", which has a
member "bool valid". You could then

#define sys_mbox_set_invalid(mbox) ((mbox)->valid = false)
---

In addition, sys_xxx_free does NOT have to invalidate a mbox or sem. The
xxx_set_invalid functions are always called separately (and after the
xxx_free function).

If you have sys_mbox_t as void * and just return NULL in the
xxx_set_invalid, you will get a NULL argument in the sys_xxx_valid
functions and you return false. If you don't get a NULL argument, you
can guess that it's a valid handle. You also could keep track of the
allocated handles.

In my app I don't free sems and mboxes, I just put them into a queue for
later reuse. But how you handle this is completely up to you.

Walter

------------------------------

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

End of lwip-users Digest, Vol 94, Issue 26
******************************************
********************************************************************************************************************************
This email message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain 
confidential and privileged information. Any unauthorized review, use, 
disclosure or distribution is prohibited. 
If you are not the intended recipient, please contact the sender by reply 
e-mail and destroy all copies of the original message. 
[Delta Energy Systems]
********************************************************************************************************************************




reply via email to

[Prev in Thread] Current Thread [Next in Thread]