Re: Talarm() problem

[Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>]

roemer@informatik.uni-frankfurt.de writes:

|>> Here is a solution to the timeout problem. The strategy is as follows:
|>> 
|>> - when a timeout expires instead of disposing it, put it on a special
|>> list of expired timeouts
|>> - in add[root]timeout first check this list if there is a timeout that
|>> has the same process and function attached and reuse it
|>> - cancel[root]timeout looks at this list, too, as well as
|>> cancelalltimeouts
|>> 
|>> I think this is the only way to reliably prevent cancel[root]timeout
|>> from cancelling the wrong timeout. Since timeouts are normally used
|>> for periodically calling a certain function, add[root]timeout will
|>> always reuse the same timout structure and thus remove it from the
|>> list of expired timeouts. I have verified this by adding a function to
|>> print out this list, and everytime i checked it was empty.

|> WARNING!

|> Be very careful with this in respect to MintNet and perhaps ehscsi.
|> MintNet currently doesn't call cancelroottimeout() on a timeout that
|> has already expired (to avoid the problem this patch intends to fix).

|> Without changing MintNet this patch will cause memory leaks! If the
|> patches will go into futher releases of Mint (Eric?) then I will
|> change MintNet to don't check whether a timeout already expired and
|> always call cancelroottimeout.

I have already thought about this, and it won't cause any memory leaks
since everytime addroottimeout is called the expired timeout will be
reused. It's even more efficient since the timeout structure does not
have to be freed and reallocated each time. There are only few timeout
functions that are used in MintNet, and every one will get a certain
timeout structure that is always reused. You don't have to change
MintNet.

Andreas.