On 13 Aug 2008, at 23:40, William Ahern wrote:
you have to decide when the incomprehensible tangle of callbacks
should be
tamed with a state machine. This sounds like one of those times.
...cut...
(2) keep a third timer event outstanding, and some logic in the
timeout
handler to detect the case that xxx finished but zzz is [relatively]
late.
Similarly, if I understand your problem, create a really simple
message/job
queue which postpones the buf write OK, etc. Either zzz or the timer
triggers execution of the job.
..cut...
Really, the example psuedo-code you've written betrays that you're
wanting
to have your cake and eat it to--no threads, but ability to leverage
the
call stack for storing state. Lua and libevent make a good
combination ;)
Aye - that sums it up very nicely. Thank you!
The reason I was hoping to have the cake and eat it is that I am
inside a REST call - i.e. a nice evhttp handler (which needs to wait
for a spread.org sp_receive() to confirm that its decoupled sp_sent()
has stuck before conforming a 200 OK or 500 Fail).
And hence if I tame this with a state-engine - or try to pospone
sending the reply by using a queue - as I am within the evhttp handler
- I fear having then re-write a fair chunk of what evhttp does so
nicely.
Thanks!
Dw
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
