wimp_poll_idle

What exactly does wimp_poll_idle do?
I was hoping it would not return to the null event until after the idle time you pass it.
However it seems to return exactly the same way that wimp_poll does, unless the value is huge (> 200000) in which case it doesn’t return at all.

This return’s like it was event_poll:
event_poll_idle (&event_code, &poll_block,200000, 0);

This one never seems to return:
event_poll_idle (&event_code, &poll_block, 300000, 0);

I assume I’m missing some logic on how this works.

Zero at the end? Shouldn’t you mask to not return Null polls?

Oh, and from memory, isn’t the return time (timenow + delay)?
Try adding your desired delay to the reply from the monotonic time call.

Sorry I can’t be more helpful – I’m in the car. ;-)

Hey! that’s wonderful!
I already put in a fudge to the wimp_poll loop to calculate when to do the rss refresh based on (timenow+delay).
All I had to do was whack in go_clock_time to event_poll_idle.

I am a very very happy camper! Now I can do some really dodgy code to do some more cpu savings :-D

Thanks very much!
Now to try and learn how to load my sprites into a dynamic memory area…and my little BBC News app should be ready for release to the masses

I assume I’m missing some logic on how this works.

I thought it was masking to determine what poll events to respond to, and how long (idle time) to leave before returning to the task “…returning control back to the task as soon as possible after the time in R2”
http://www.riscosopen.org/wiki/documentation/show/Wimp_PollIdle

Rick: Sorry I can’t be more helpful – I’m in the car. ;-)

Passenger I assume, or is that French driving rules in play? :-)

It looks like poll_idle, will cause the poll not to return the null event until after the idle time.
Which is clock()delay.
In my case I load the RSS feed and graphics with the idle time set to zero.
Then once finished loading, I set the idle time to be clock()refresh_rate.
Then it sets idle time to zero again and loads the RSS Feed and then when it’s finished sets it to be clock()+refresh_rate ad infinitum.
As there are quite a few selects that are returning “no data to read” I can add something to say if there is a select “no data to read” event on the socket, I can add a few ms onto the next time it comes back into the null event, and do some logic based on amount of data read.

i.e. if the maximum amount read is small then increase the poll_idle time to allow the network buffer to fill more before coming back into the code again [ on the ES it looks like the network buffer size is around 17k ]
So if I only read say 4k of data then I will increase the poll_time and if the next time I read more data in then increase the poll_time until either I reach my internal buffer size or the amount of data I read each time does not increase.

That’s the theory anyway, if that makes any sense!

If you want to see the poll rates of your app in action, and its effect on cpu time and other apps, you could try my TaskUsage

It looks like poll_idle, will cause the poll not to return the null event until after the idle time.

That’s my understanding of the documentation.
I believe the idea is to ensure that applications that don’t need attention except once in a while don’t claim undue processor time. Net effect: those that do need regular attention get a better service.

That was my hope, however using Martins Usage app, showed me that it isn’t working.
I forgot to remove my fudge to do the timing inside the NULL return switch…

However if I use wimp_pollidle instead of event_poll_idle I get “Invalid Object Id (0×0) (0×0) (0×1).”
Which is interesting…
Not related though, I assume that’s mixing toolbox and non toolbox stuff.

So for now I’m assuming pollidle is broken, either in the toolbox or in RO 5.19/5.21, I’ll keep digging

That was my hope, however using Martins Usage app, showed me that it isn’t working.

You do have Null events enabled, yes? Otherwise you’ll never get Null events, regardless of PollIdle time.

Also be aware that all other enabled events are returned to you immediately. You may need to take that into consideration when, and how, you calculate the next PollIdle time.

Mmm… Been reading the PRM on this.

Question occurs to me. If you have no specific need for null polls, is it better to call Wimp_Poll with nulls masked out or Wimp_PollIdle? Surely a normal poll without null events would only return when there is something of interest, and it would save the overheads of setting up a time counter, and for the Wimp to periodically check it? Okay, we could perhaps run the additional code a million times before we clock up a second’s worth of delay, but it’s the principle here… Which is technically the least load on the system?

If you don’t need the null code, mask it out – this is the most efficient for the system.

So…
PollIdle will return a NULL event, but NULL events need to be disabled otherwise it will return as normal?
Is that correct, I think I was assuming NULL event was needed otherwise PollIdle wouldn’t return…
Which would explain why my PollIdle was always returning…

If you have no specific need for null polls, is it better to call Wimp_Poll with nulls masked out or Wimp_PollIdle?

You’d definitely want Wimp_Poll in such a case. Less overhead and no Null events at all.

PollIdle will return a NULL event, but NULL events need to be disabled otherwise it will return as normal?

No, Null events need to be enabled. Here’s a simple testcase (needs Reporter):

DIM Blk% 256
Quit% = FALSE
Mask% = 0
SYS "Wimp_Initialise",300,&4b534154,"Test Null events",0 TO Handle%
REPEAT
  SYS "OS_ReadMonotonicTime" TO Time%
  SYS "Wimp_PollIdle",Mask%,Blk%,Time% + 100,0 TO Reason%
  IF Reason% = 0 THEN *Report "Null event"
  IF Reason% = 17 OR Reason% = 18 THEN
    IF Blk%!16 = 0 THEN Quit% = TRUE
  ENDIF
UNTIL (Quit%)
SYS "Wimp_CloseDown",Handle%,&4b534154
END

With Mask% = 0 you’ll get a Null event once a second. Set Mask% to 1 and you’ll never get a Null event.

If the line…
IF Reason% = 0 THEN *Report "Null event"

is replaced by…
*ReportPoll (Reason%)

it will display each reason code, with the time it is returned.
Makes it easier to see all that happens, and when.

my little BBC News app should be ready for release to the masses

http://www.chris-johnson.org.uk/software/3party.html#ticker

@Martin: That’s a great ticker, that’s what made me want to write my application.
I’m going for something a little “richer” than just plain text.
I’m hoping it will be a PoC application, where I am testing code for socket I/O.
“BBCNews” will be the testbed, then a full-fat RSS reader, then a Jabber client, then hopefully an EMail/Groupware Client (full fat)
As the applications are likely to use large amounts of CPU and RAM, I need to minimise all CPU and RAM usage I can – wherever I can.

But if there are any ideas for any RISC OS socket programs, feel free to suggest.

@Fred: Thanks, got it working now. I was using the wrong “time”.
And cheers for clarifying the PollIdle, I was starting to get confused.
Just when I thought I’d squished all the bugs another one turns up! ;-)
Endless fun!

@Fred: Thanks, got it working now.

No problem. Glad to hear it helped you getting your code to work. It would be good to see some new code coming to RISC OS, so Good Luck. :-)