<nickrw>
so user runs !start command to kick off registration, timer is created to raise an event to finish signup 5 minutes later
<dominikh>
(I won't comment on the fact your code is racy for now, it probably doesn't matter here)
<dominikh>
but yeah, I see the issue :)
<dominikh>
add a :start_automatically => false to your Timer() call. there's, uhm. a really silly bug/flaw in the API
<dominikh>
timers get stopped on a disconnect and started on a connect. issue here is, they forget how often they fired.
<dominikh>
so if anyone used !start, after a reconnect it will run again after the delay
<nickrw>
ah cool
<nickrw>
racy as in race condition?
<dominikh>
(fwiw, there's also a memory leak involving timers, but I'm hoping you don't create enough timers to run into it any time soon)
<nickrw>
I've started to address that recently
<dominikh>
yup, racy as in race condition
<nickrw>
I've yet to encounter an actual race condition bug, but I did use #synchronize for something recently
<nickrw>
but only because the bot itself was raising an event that two plugins were responding to, and were going to modify the same data
<dominikh>
actually I'm not sure if ||= is atomic, but let's assume it's not (I don't think it is.): if two people use !start at the same time and shared[:timer] isn't set yet, you might call Hash.new twice, possibly losing one of the timers you add
<nickrw>
oh interesting
<dominikh>
also, what I am wondering about your hook_async right now: what happens if you run it multiple times with the same method? you seem to be only storing one timer
<nickrw>
yeah, aware of that - limitation of the design but I don't yet have the same event firing multiple times in a row
<nickrw>
I thought about making it support multiple events of the same method at the time, but I couldn't think of a good way to clean up old ones
<nickrw>
some sort of GC to look through it for dead threads
<dominikh>
brb
<dominikh>
just store the timers in an array and #delete them when you're done. same way you're doing now, but with an Array#delete with the Timer object instead
<nickrw>
oh good point
<nickrw>
not sure how to have hook_cancel handle it though, apart from just cancelling them all
<dominikh>
is that a user command? then no way other than introducing some sort of ID system
<nickrw>
not directly, no
<nickrw>
other plugins call hook_cancel upon some user interaction in order to interrupt normal state change
<nickrw>
but at present, there is only one of each event at any one time
Spami has quit [Quit: This computer has gone to sleep]
Spami has joined #cinch
Spami has quit [Ping timeout: 264 seconds]
jonahR has joined #cinch
rikai has quit [Read error: Connection reset by peer]
rikai has joined #cinch
space_ is now known as Spaceghost
Spaceghost has quit [Changing host]
Spaceghost has joined #cinch
postmodern has joined #cinch
Spaceghost has quit [Read error: Connection reset by peer]