| 00:37.52 | Twingy | All aboot the pentium's werd |
| 01:39.05 | *** join/#brlcad DTRemenak (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) | |
| 07:28.20 | *** join/#brlcad DTRemenak|RDP (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) | |
| 08:30.05 | *** join/#brlcad DTRemenak (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) | |
| 12:50.40 | *** join/#brlcad rossberg (n=rossberg@bz.bzflag.bz) | |
| 12:51.47 | CIA-9 | BRL-CAD: 03bob1961 * 10brlcad/src/tclscripts/archer/Archer.tcl: Mods to remove the expand button when in "Basic" mode. There's also a minor tweak of the aboutDialog's size. |
| 12:57.55 | CIA-9 | BRL-CAD: 03d_rossberg * 10brlcad/src/librt/db_open.c: |
| 12:57.55 | CIA-9 | BRL-CAD: do not close a mapped file while the database instance is still in use |
| 12:57.55 | CIA-9 | BRL-CAD: as db_clone_dbi does not increment dbi_mf->uses |
| 13:50.54 | brlcad | rossberg: i think i see the problem with just what you've said, but would it not be better to increment dbi_mf uses instead of not closing it? |
| 13:51.24 | brlcad | otherwise uses is .. useless ;) |
| 13:54.54 | brlcad | dbi_uses is only incremented in db_open, so it should be safe to increment mf->uses there on the dbi clone |
| 13:59.03 | rossberg | brlcad: i'm not sure but i think the handling of mf->uses is ok |
| 13:59.35 | rossberg | dbi_uses will be incremented in db_clone_dbi too |
| 14:00.22 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/librt/g_submodel.c: remove bad commented-out increment of the dbi_uses. it might benefit to just clone the dbi, but seems unnecessary for a plot routine |
| 14:00.35 | brlcad | the handling of mf-> uses is okay until you clone the dbi, no? :) |
| 14:01.17 | rossberg | without clone the whole thing is trivial |
| 14:01.19 | brlcad | the issue is perhaps that the mapped files are globally shared |
| 14:01.42 | brlcad | so cloning the dbip doesn't give you a new open mapped file descriptor |
| 14:02.21 | rossberg | no: cloning only increments the reference counter (+ something else) |
| 14:02.33 | rossberg | this is for garbage collection |
| 14:02.46 | brlcad | right, on the dbi |
| 14:09.40 | rossberg | mf->uses counts references to a mapped file and dbi_uses counts references to a dbip |
| 14:11.05 | rossberg | consequently adding or removing a reference to a database instance does not change the references to a mapped file |
| 14:11.27 | rossberg | it is still the same database instance which refers to this file |
| 14:14.20 | brlcad | and that seemed like a bug to me -- adding or removing a reference to a database instance could conceivably change the number of references to a mapped file |
| 14:15.09 | brlcad | i think it'll work either way just because how mapped files are these global entities (especially if you just don't free them), just uses memory that could potentially be released |
| 14:16.43 | rossberg | but this are all indirect references (as the are higher level references via rtip too) |
| 14:18.20 | rossberg | it may be more clear if you think of dbi as an object |
| 14:19.45 | rossberg | independent of the number of references to this object, it is still only one object |
| 14:23.51 | rossberg | btw, it looks like the true purpose of db_clone_dbi is the registration of an additional client |
| 14:51.39 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/librt/db_open.c: allow for clientless cloning and closing of dbip instances where only the uses count is of interest. no need to stash null clients even though the ptbl will record them, just ignore them. |
| 14:54.17 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ged.c: avoid incrementing the dbi_uses counter directly -- do a clientless clone of the dbip instead |
| 16:05.21 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) | |
| 16:52.58 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) | |
| 18:48.37 | *** join/#brlcad DTRemenak|RDP (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) | |
| 18:48.51 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) | |
| 20:14.56 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/ispar.c: gah, reduce the massive WIN32 block to just the section that mattered so that kill() is not invoked on a bu_bomb().. should eventually contain a WIN32-esque method for killing a parent process gracefully ala kill() |
| 22:37.59 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/bomb.c: avoid passing additional format arguments to fprintf() to avoid potential buffer allocations. very nominal benefit, but can conceivably help with certain crashes and implementations of fprintf(). |
| 23:29.05 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) | |
| 23:31.39 | *** join/#brlcad justin_ (n=justin@c-68-33-163-43.hsd1.md.comcast.net) | |