> The problem I see is in the restart function. What I have seen is
> restart being called twice with the same tid. Restartid[port] is
> cleared on the first call, so when the second call with the same tid
> shows up, there's no longer a port associated with it.
I'm not sure why this would happen. Once the timer pops for a certain
timer id, it should not be called again as far as I am able to
determine. The timeout is removed by the internal handler before your
callback is invoked, so I find it hard to understand how the timeout
handler might be called more than once for the same timeout id.
How are you determining that the timeout for a particular timer id is
being called more than once?
> What happens when restart code is being run, then reexecuted (new
> timeout) before its done? I would think that the variables from the
> executing copy are pushed until the new call is complete, then
> pulled back in and finished.
The next timeout shouldn't ever occur until your restart code executes
unless you are executing a fl_check_forms() call or calling one of the
goodies, which call fl_do_forms() internally. Until you return
control to the XForms internal main loop a timeout can't occur. If
you do cause the XForms main loop to be called (with fl_check_forms()
or fl_do_forms() then some strangeness could possibly happen since the
timeout chain could be caused to be traversed more than once, I
suppose, since there is no mechanism to lock reentrancies out.
The timeout callback doesn't use the alarm() function, so it isn't
causing a signalh to be fired.
Are you doing any XForms calls within your timer handlers other than
the fl_add_timeout()? If so, which ones? It shouldn't make any
difference but it's worth asking.
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/