How to handle timeout periods in Rebol 3 circuits

A common way to trigger the asynchronous I / O event system in Rebol 3 is to wait on the port. To check the timeout, a value from the schema is added to the wait block.

wait [port timeout]

      

But the minimum timeout for a small email message may not be suitable for a file with several megabytes.

What's the best way to handle this? If you are still receiving data, can you update the waitlist while your script is receiving data so you don't waste extra timeout?

+3


source to share


3 answers


I think the port timeout should be triggered based on the packet time, not the full request. So setting a timeout of 30 seconds by email means you didn't receive the package in 30 seconds.

Since packets tend to be small, they arrive quickly rather than receive them over a long period of time, this will be an indication of a network / server failure where you want to timeout. (The exception is that packet aggregation occurs, but there will still not be as much aggregation that there is usually a long delay.)



All this said, I'm not sure if they are implemented in R3. Based on the previous comment, I think not. The networking system was one of the first pieces I wrote for R3, and it was lean and average, but of course it could get some attention.

+5


source


It looks like it hasn't been implemented yet. In this post http://www.rebol.net/wiki/Ports_and_Schemes:_Issues issue 9: Timeouts, says Karl



The following ports implemented by the device model already include the timeout function. It is not currently enabled, but it should be. This would meet the first requirement for actions such as CONNECT or READ and their associated timeouts. This method does not use a common timer port, as lower-level port devices will have trouble making a higher-level call to that port.

At higher levels, we have always planned to provide a TIMER circuit for such ports. It should be possible to make this available soon because the main time code and kernel-level wake mechanism is already implemented (for Win32 system API).

+1


source


how about a loop? forever [wait [port 1] if magic-port-has-data? port [process]]

0


source







All Articles