Re: [core libraries] Improved TimerManager API

Hello, If I remember correctly, the current algorithm of TimerManager was proposed by me. That is, TimerManager is waken up only when the internal PSQ is changed. (See abda03be6794ffd9bbc2c4f77d7f9d534a202b21) I would like to understand what failure (or success) means. Does it include BOTH TimerManager is not waken up AND poll() system call returns -1? I guess that this change is a little bit harder than people expect. --Kazu

Andrew has done a lot of work with the Event Manager. Perhaps he has a more nuanced opinion on this, but I don't see any reason why not. So I am +1.

Out of curiosity, what are you doing with the event manager?

On Sat, May 30, 2020, 10:38 PM George Wilson wrote:

...

Admittedly I'm not familiar with that module, but this change seems easy to make. It seems as though these functions don't exactly "fail"; rather they don't bother updating the queue if the change would be redundant. Is that correct? Could you explain why you want to detect this?

Cheers, George

On Wed, 13 May 2020 at 09:59, Mitchell Rosen wrote:

...

Hi all,

I'd like to propose we modify GHC.Event.updateTimeout and

GHC.Event.unregisterTimeout to each return a Bool, indicating whether the update/unregister was successful.

...

Thanks, Mitchell

-- You received this message because you are subscribed to the Google

Groups "haskell-core-libraries" group.

...

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAKYGvgMMPdWUhjT_C%... .

-- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CABzzMazjVQBz5C6wED... .