| 00:03.36 | *** part/#asterisk-dev alecdavis (~alecdavis@202.36.76.21) |
| 02:23.45 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 05:48.31 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 05:48.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:53.08 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 06:53.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:12.15 | wedhorn | doing some work on polling in skinny and have come to a bit of an issue, can use ppoll to overcome a possible race condition, but guessing it's probably not a reasonable approach given it doesn't seem that widely adopted |
| 07:13.19 | wedhorn | Any suggestions, could probably use pthread_cancel after pushing in some cleanup stuff (given the race is related to destroying a thread) |
| 07:13.41 | wedhorn | Does this approach sound the best? Any other ways? |
| 07:15.57 | wedhorn | Or possibly change from multithreaded to single thread for reading network stuff and do non-blocking polls... |
| 07:30.27 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 07:30.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:48.27 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 07:48.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:08.58 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:101f:804b:e689:e159) |
| 08:20.12 | *** join/#asterisk-dev suneye (~atcmmi@119.122.30.136) |
| 09:30.55 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 09:30.55 | *** join/#asterisk-dev LieutPants (~LieutPant@asterisk/documenteur-extraordinaire/blitzrage) |
| 09:30.55 | *** mode/#asterisk-dev [+o LieutPants] by calvino.freenode.net |
| 09:32.23 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 09:41.34 | *** join/#asterisk-dev bulkorok (~chatzilla@gw1.pinguin.ag) |
| 09:53.06 | *** join/#asterisk-dev Greenlight (~email@cpc1-dund9-0-0-cust142.16-4.cable.virginmedia.com) |
| 09:56.14 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:56.15 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:45.35 | *** join/#asterisk-dev LieutPants (~LieutPant@asterisk/documenteur-extraordinaire/blitzrage) |
| 10:45.35 | *** mode/#asterisk-dev [+o LieutPants] by calvino.freenode.net |
| 11:09.02 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:34.33 | *** join/#asterisk-dev LieutPants (~LieutPant@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:34.34 | *** mode/#asterisk-dev [+o LieutPants] by calvino.freenode.net |
| 12:35.13 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:35.13 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:49.51 | file | I almost thought it was Tuesday for a second >_> |
| 12:50.15 | file | leedm777, ah you are in here! |
| 12:50.23 | leedm777 | Yes! |
| 12:50.49 | leedm777 | file: Cache consistency is one of the two hard problems in computer science. |
| 12:50.53 | file | aye |
| 12:51.43 | file | for testing I just disabled use of taskprocessors in stasis, and it confirmed my logic worked :D |
| 12:52.29 | leedm777 | whee! Look ma, no threads! |
| 12:53.13 | leedm777 | Stasis will guarantee message ordering, but I have thought about putting any guarantees on the cache itself. |
| 12:53.43 | file | I'm torn whether you'd always want a guarantee or not |
| 12:53.49 | leedm777 | True. |
| 12:54.29 | file | if you are reacting and need a guarantee then subscribe imo, I don't want to do that because it's a lot of overhead >_> |
| 12:54.44 | leedm777 | Yup. |
| 12:55.02 | file | and when I'm called I know something has likely changed |
| 12:55.07 | leedm777 | The code as-is wouldn't do that, because the subscriber runs asynchronously from the cache update. |
| 12:56.23 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-vgdculqhzpbczqqu) |
| 12:56.39 | leedm777 | file: these are channel snapshots from the channel cache, right? |
| 12:56.48 | file | and endpoint |
| 12:57.32 | leedm777 | Well, the two different caches certainly have no consistency guarantees between them. |
| 12:58.44 | file | I grab an endpoint snapshot to get the state, and also the channels - then if channels are present grab their snapshots to determine further state |
| 13:00.39 | file | if the above functionality (guaranteed that any pending changes are done) exists then, despite no consistency between both, it should yield the "correct" result |
| 13:01.30 | leedm777 | You can guarantee that any pending updates to the cache have been processed. |
| 13:01.44 | leedm777 | What you can't guarantee is that further updates have not been processed. |
| 13:02.09 | file | yeah, that's fine because the function which queries for the device state will end up getting called again |
| 13:03.03 | leedm777 | There are probably pathological cases where the results are consistently inconsistent. |
| 13:03.20 | leedm777 | wonders at all the double negatives file is forcing me to type |
| 13:04.09 | leedm777 | If you have a situation where channels associated with an endpoint are constantly in a state of flux for some period of time, during that time it would be hard to get consistent state from the caches. |
| 13:04.43 | leedm777 | It will get eventually consistent. |
| 13:04.44 | file | I'm only looking at the channel state which is generally down -> ring/ringing -> up/busy |
| 13:18.39 | leedm777 | So eventually consistent is probably good enough. |
| 13:18.44 | file | yup, the device state callback will get called when the change occurs and it'll just determine the new state every time |
| 13:19.08 | file | I'm pretty happy it can be done completely with stasis |
| 13:19.09 | *** join/#asterisk-dev tm1000 (~tm1000@li584-160.members.linode.com) |
| 13:19.14 | *** join/#asterisk-dev aimka (~aimka@unaffiliated/aimka) |
| 13:19.15 | leedm777 | Yup. I, too, am happy. |
| 13:19.16 | leedm777 | For a certain definition of happiness, which sadly does not involve a beach. |
| 13:19.58 | leedm777 | file: of course, now you've got me thinking about how to achieve read consistency between multiple Stasis caches. |
| 13:20.00 | file | SOWWY |
| 15:17.45 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 15:17.45 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 15:19.25 | *** join/#asterisk-dev aimka (~aimka@unaffiliated/aimka) |
| 15:24.30 | file | leedm777, a... ha |
| 15:25.53 | leedm777 | file: ? |
| 15:26.05 | file | I understand what is happening |
| 15:26.27 | leedm777 | Does this understanding lead to enlightenment? |
| 15:26.38 | leedm777 | Or at least a fix for your probleM? |
| 15:26.48 | file | it's the message router, it subscribes so it is not guaranteed that my snapshot will be up to date yet again |
| 15:31.38 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 15:33.57 | file | leedm777, I'm curious - why was the addition of the channel_ids to the endpoint done that way |
| 15:35.24 | leedm777 | file: it seemed like a good idea at the time. |
| 15:36.20 | file | I'd expect it to be done immediately when ast_endpoint_add_channel is called - you are then guaranteed for the channel to be on the endpoint, and since it publishes channel state as well you are guaranteed for it to exist in the cache |
| 15:37.20 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 15:39.59 | leedm777 | file: at the time, eventually consistent was good enough. But if you need to make add_channel synchronous, that should be fine. |
| 15:40.37 | file | nods |
| 15:41.57 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:41.57 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:42.00 | leedm777 | The removal of the channel from the endpoint should still be asynchronous, though. Otherwise you'll get snaphots after the channel has been removed from the endpoint. |
| 15:42.20 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 15:42.20 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 15:42.46 | file | yeah I'm not touching that |
| 15:42.54 | Qwell | opticron: transclude? O.o |
| 15:42.55 | leedm777 | Good. |
| 15:43.16 | opticron | gah, did I say it again? |
| 15:43.33 | opticron | always has mediawiki on the mind |
| 15:43.38 | opticron | Qwell, xi:include |
| 15:43.43 | Qwell | mmk |