| 00:16.39 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 00:21.18 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 02:39.32 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:39.32 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:37.38 | *** join/#asterisk-dev dant (~dant@180.190.49.237) |
| 04:32.07 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 04:40.34 | coreyfarrell | gtjoseph: so you're talking about naming the macro that actually does an insert AST_VECTOR_INSERT_AT, renaming AST_VECTOR_INSERT to AST_VECTOR_REPLACE? |
| 04:42.06 | gtjoseph | Nope. AST_VECTOR_INSERT originally did a replace, not insert. The new AST_VECTOR_INSERT really does an insert. |
| 04:42.20 | gtjoseph | I was siggesting that I could name the new INSERT INSERT_AT |
| 04:42.40 | gtjoseph | that way anyone trying to user INSERT would get a compile failure |
| 04:43.14 | gtjoseph | oh, re-reading what you said, yes. :) |
| 04:43.24 | coreyfarrell | so I'm personally fine with that. my biggest worry is someone using INSERT and not realizing the change happened. that would probably be a nasty bug. |
| 04:43.42 | gtjoseph | agreed. |
| 04:44.02 | gtjoseph | I checked with mjordan eariler today and he was ok with doing this in 13. |
| 04:44.34 | gtjoseph | I'll do the rename and re-submit |
| 04:46.09 | coreyfarrell | compatibility is a pain! |
| 04:46.29 | gtjoseph | :) |
| 04:47.39 | coreyfarrell | sometime this weekend I'll give the vector change a better review. |
| 04:48.30 | gtjoseph | cool |
| 04:48.33 | Juggie | lol |
| 04:48.43 | Juggie | i heard the stl has all this for you in a modern language! :) |
| 04:49.15 | coreyfarrell | thanks for hitting so many of my reviews lately. I've been working on an updated module loader and keep coming up with other things that have to be done first. |
| 04:50.12 | gtjoseph | yeah, that's the same reason for the vector changes. |
| 04:51.02 | coreyfarrell | what are you working on that brought you to vector changes? |
| 04:51.18 | gtjoseph | sorcery wizard changes |
| 04:51.34 | gtjoseph | can't use a container any more because i have to insert at specific locations |
| 04:52.19 | gtjoseph | i think i woke mjordan up when i mentioned him a few minutes ago. |
| 04:52.32 | gtjoseph | he just logged out, :) |
| 04:52.35 | coreyfarrell | ha |
| 04:54.23 | coreyfarrell | so one more change I'm thinking of for OPTIONAL_API is to make it always enabled.. that way we'll get rid of one more ABI option. |
| 04:54.58 | gtjoseph | i never really understood what it did anyway |
| 04:55.03 | coreyfarrell | I think the fact that it can be disabled is just left-over from when it was using weakref magic that wasn't supported on all platforms |
| 04:55.25 | coreyfarrell | you mean you don't understand what optional api does? |
| 04:55.59 | gtjoseph | yeah |
| 04:56.32 | coreyfarrell | so normally for res_monitor to call a C function in func_periodic_hook, it would need to link to the symbol |
| 04:57.22 | coreyfarrell | optional_api makes it so func_periodic_hook registers a function to the core, and res_monitor asks the core if it has that symbol. if not a default stub is used |
| 04:57.34 | gtjoseph | ah |
| 04:57.53 | coreyfarrell | that way res_monitor can call the function if the other module is loaded. if not it's ok we don't get symbol not found error loading res_monitor |
| 04:58.17 | gtjoseph | now it makes sense |
| 04:59.07 | coreyfarrell | in asterisk 11 optional_api uses weakref magic that only works on certain compilers, hence the ability to disable it. it was rewritten for 12 or 13 and the new API only uses __attribute__((constructor)). |
| 05:09.04 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-qobgvqlmjoiiyxsy) |
| 06:10.02 | *** join/#asterisk-dev drmessano^ (~nonya@pdpc/supporter/active/drmessano) |
| 07:30.41 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:30.41 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:11.32 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 08:11.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:02.29 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 13:13.13 | *** join/#asterisk-dev dant_ (~dant@180.190.49.237) |
| 14:08.54 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-vvhnzgmiscjtwctr) |
| 14:18.07 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 14:27.50 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:09.09 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-3-44.dhcp.nwtn.ct.charter.com) |
| 15:31.19 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 15:35.50 | coreyfarrell | gtjoseph: i'm looking at the vector changes, the rdlock/wrlock might concern me. I think I remember rmudgett saying that you can't recurse rdlock/wrlock. |
| 15:41.08 | gtjoseph | correct, do you see a recursion? |
| 15:41.44 | coreyfarrell | ok so AST_RWVECTOR_RDLOCK and AST_RWVECTOR_WRLOCK are \internal ? |
| 15:42.49 | *** join/#asterisk-dev Marquis42 (~mrbmw@d14-69-246-193.try.wideopenwest.com) |
| 15:43.10 | gtjoseph | well, they could be |
| 15:43.41 | coreyfarrell | if code using rwvector used rwvector_rdlock or wrlock then performed multiple actions it would recurse |
| 15:44.06 | gtjoseph | yeah that's true. |
| 15:44.26 | gtjoseph | in an earlier version, that wasn't the case |
| 15:44.38 | gtjoseph | i'll remove the external calls to WR/RD lock |
| 15:44.46 | gtjoseph | they're no longer needed |
| 15:45.13 | coreyfarrell | it seems like we either 1) add __ prefix to those two macro's, mark \internal, or 2) add a flag to OBJ_NOLOCK on all macro's (yuck) |
| 15:45.46 | coreyfarrell | or just get rid of the macro's and call ast_rwlock_rdlock / wrlock directly in the rest of the macros. |
| 15:45.56 | gtjoseph | exactly where i was going |
| 15:46.02 | gtjoseph | no need for them anymore |
| 15:46.30 | coreyfarrell | anyways I was asking here because I wasn't 100% sure recursive rwlock was an issue, I'll comment to gerrit so others know why you are making the changes. |
| 15:46.50 | gtjoseph | cool |
| 16:11.21 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 16:11.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:31.41 | coreyfarrell | I've gotten spoiled by ccache... really sucks when you get 100% cache misses :( |
| 16:32.00 | gtjoseph | :) |
| 16:32.09 | file | it's a harsh world |
| 16:32.35 | file | if only the cache were in the CLOUD |
| 16:32.54 | file | I've been rewatching Steve Jobs Apple keynotes/announcements and it's been fun to add "in the cloud" to various statements |
| 16:33.04 | file | many have come true |
| 16:38.19 | coreyfarrell | find -name '*.o' totals 280MB in one of my master builds, so that would be a lot of downloading. I think in that case my CPU is still faster than my internet. |
| 16:53.51 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 19:23.39 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:23.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:42.15 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 20:16.53 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 20:31.44 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-vlunwztuhvdxfrao) |
| 20:47.28 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 21:57.10 | gtjoseph | coreyfarrell: what did you mean by ... "I do think we need read or write locking for every operation that reads or writes vec. Applies to every use of AST_VECTOR_* in this test." |
| 22:18.11 | coreyfarrell | some AST_VECTOR_* macro's don't have AST_RWVECTOR_* counterparts. user code should not use AST_VECTOR_GET on an RWVECTOR. |
| 22:18.22 | coreyfarrell | gtjoseph: ^ |
| 22:18.55 | gtjoseph | yep, ok. i wasn't sure you were making a separare point or expounding on the first. |
| 22:20.02 | coreyfarrell | well one "solution" to the first point would be: #define AST_RWVECTOR_GET(...) AST_VECTOR_GET(__VA_ARGS__) |
| 22:20.35 | coreyfarrell | the second point was that we probably shouldn't do that, and should make all rwvector macro's do lock protection. |
| 22:20.37 | gtjoseph | actually because of the assert i added a lock around it. |
| 22:20.52 | gtjoseph | oh yep that's what I did |
| 22:22.01 | coreyfarrell | i'll take a look at it again when it cools down here |
| 23:43.52 | *** join/#asterisk-dev snuff-work (~blatus@203.87.61.22) |
| 23:43.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |