[lwip-users] Re: [lwip] sys_timeout()

[Adam Dunkels]

Hi!

On Friday 19 October 2001 12:19, you wrote:
> My mistake was, that I saw sys_mbox_fetch() as an isolated function
> which could be implemented just based on its own arguments.
> (This way, the timeout implementation would have needed internal
> OS infos!)
>
> Maybe we should somewhere add a short specification about how
> sys_mbox_fetch() is supposed to behave.
>
> For example sys_mbox_fetch() and sys_sem_wait() could be given
> a comment like this:
>
> "This is an operation with a timeout. The timeout is not specified as an
> argument to this function call, but as a global mechanism for this thread.
>
> The mechanism involves all calls to sys_timeout(), sys_mbox_fetch(),
> and sys_sem_wait() which are made in this thread, and uses global data.
> For further info read ..."
>
> (I think your above example explains it well. Unfortunately I had
> not seen something like it, although I thought I had read your docs.)

Yes, documentation for the OS emulation layer is definately missing!

> Another way to make things easier to understand might be to pass a pointer
> to the data structures used by the timeout implementation, when calling
> sys_mbox_fetch() or sys_sem_wait().

No, that would make the code that uses the OS emulation layer unnecessary 
complex. I think it is more appropriate for the OS emulation layer to keep 
track of things such as threads, timers and IPC mechanisms, and not the 
application.

The plans for the sys_arch layer in 0.5 is that the sys_mbox_fetch() and 
sys_sem_wait() will take an additional argument that specifies the maximum 
time to wait for the mailbox or the semaphore. The timer scheduling code 
would then be moved out of the sys_arch file and into a generic sys.c file.

Anyway, thanks for your input and I am glad that the info helped!

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam

[This message was sent through the lwip discussion list.]