gtk-gnutella-devel Digest, Vol 25, Issue 3
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 25, Issue 3
by gtk-gnutella-devel-request
::
Rate this Message:
Send gtk-gnutella-devel mailing list submissions to
gtk-gnutella-devel@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel or, via email, send a message with subject or body 'help' to gtk-gnutella-devel-request@... You can reach the person managing the list at gtk-gnutella-devel-owner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of gtk-gnutella-devel digest..." Today's Topics: 1. Re: [was: DHT uptime.] (Christian Biere) 2. Re: [was: DHT uptime.] (Raphael Manfredi) 3. Re: [was: DHT uptime.] (Christian Biere) 4. Re: [was: DHT uptime.] (Raphael Manfredi) 5. Re: [was: DHT uptime.] (Christian Biere) 6. QRP changes. (Bill Pringlemeir) 7. Re: QRP changes. (Raphael Manfredi) ---------------------------------------------------------------------- Message: 1 Date: Tue, 16 Sep 2008 17:55:44 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] [was: DHT uptime.] To: gtk-gnutella-devel@... Message-ID: <20080916155544.GA23503@...> Content-Type: text/plain; charset=utf-8 Raphael Manfredi wrote: > Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel: > :I don't see what lookup_is_alive() is good for. It is not valid C if the > :pointer actually references a freed object as per C standard section 6.2.4. If > :you want to use weak references, look at core/nodes.c and "node_id". You have > :to use numeric IDs, not pointers to track objects beyond their life-cycle. > This code is perfectly valid as the pointer is used only as an integer here, > as a key in the hash table, and is never de-referenced unless it is valid Nobody said a word about dereferencing and if you had actually read the section, you'd know that just using the pointer's value leads to undefined behavior. > (presence in the table means the pointer is valid). Then you don't need the check for "lid" at all. If it's supposed to be a consistency check that's fine but then it should be an assertion check. If you intend to leave dangling pointers in the table and use the check to avoid recycled memory, then it's not. > Anyway, this is not the problem here. Again, I didn't say anything like that. It is a problem that became only apparent to me due to another around this code. -- Christian ------------------------------ Message: 2 Date: Tue, 16 Sep 2008 16:54:36 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] [was: DHT uptime.] To: gtk-gnutella-devel@... Message-ID: <gaoocc$dh$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel: :Nobody said a word about dereferencing and if you had actually read the :section, you'd know that just using the pointer's value leads to :undefined behavior. That C is just braindead. If you look at the flow, you'll see that the pointer's value is actually not used as a pointer but as an integer. The fact that it is carried by pointer variables is just due to the fact that the hash table only works with pointers. :> (presence in the table means the pointer is valid). : :Then you don't need the check for "lid" at all. If it's supposed to be a :consistency check that's fine but then it should be an assertion check. :If you intend to leave dangling pointers in the table and use the check :to avoid recycled memory, then it's not. If the pointer is present in the table, then it is allocated, not dangling. Also, these pointers are always allocated as far as the implementation goes because they were allocated through malloc() underneath. The walloc() layer on top of that merely redistributes the allocated space among objects, but the space is not really freed. None of this memory is really freed. Raphael ------------------------------ Message: 3 Date: Tue, 16 Sep 2008 19:39:00 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] [was: DHT uptime.] To: gtk-gnutella-devel@... Message-ID: <20080916173900.GA12286@...> Content-Type: text/plain; charset=utf-8 Raphael Manfredi wrote: > Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel: > :Nobody said a word about dereferencing and if you had actually read the > :section, you'd know that just using the pointer's value leads to > :undefined behavior. > > That C is just braindead. What's more braindead: writing code in a language of which you never bothered to read the specification of or some odd rule whose purpose you don't grasp or like? > If you look at the flow, you'll see that the > pointer's value is actually not used as a pointer but as an integer. That's just nonsense. > The fact that it is carried by pointer variables is just due to the fact > that the hash table only works with pointers. Nobody forces you to use GarbageHashTable or whatever the 'G' in GLib stands for. > :> (presence in the table means the pointer is valid). > :Then you don't need the check for "lid" at all. If it's supposed to be a > :consistency check that's fine but then it should be an assertion check. > :If you intend to leave dangling pointers in the table and use the check > :to avoid recycled memory, then it's not. > If the pointer is present in the table, then it is allocated, not dangling. Then what is the purpose of checking 'lid'? It seems pmi->nl can actually be a dangling pointer and this is the point of the check. The code could be made standard compliant by using pmi->lid instead of pmi->nl because 'lid' already maps to either 'nl' or NULL. Likewise, 'nl' could be carried around as an integer instead of a pointer. Admittedly, a GarbageHashTable defeats this by casting it back to a pointer - if you use that directly as key - which you don't have to. > Also, these pointers are always allocated as far as the implementation > goes because they were allocated through malloc() underneath. The walloc() > layer on top of that merely redistributes the allocated space among objects, > but the space is not really freed. None of this memory is really freed. A very poor excuse. walloc() is supposed to be transparent to malloc() and you can compile gtk-gnutella so that it uses malloc() all the time. In fact for debugging that's highly recommended and by not adhereing to the standard you make just this more difficult. -- Christian ------------------------------ Message: 4 Date: Tue, 16 Sep 2008 18:46:50 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] [was: DHT uptime.] To: gtk-gnutella-devel@... Message-ID: <gaouuq$kin$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel: :Then what is the purpose of checking 'lid'? It seems pmi->nl can actually :be a dangling pointer and this is the point of the check. The code could :be made standard compliant by using pmi->lid instead of pmi->nl because :'lid' already maps to either 'nl' or NULL. Likewise, 'nl' could be carried :around as an integer instead of a pointer. Admittedly, a GarbageHashTable :defeats this by casting it back to a pointer - if you use that directly :as key - which you don't have to. I perfectly know I'm handling a possibly dangling pointer value, and this is the purpose of the hash table. I know I could have used an ID in the table, but as it is a running count it would have meant using a 64-bit ID and that would imply the use of 64-bit atoms, and I don't want that. But let's face it: this code works fine as it is. An implementation of a C compiler that would put a level of indirection to all pointer accesses just to prevent using a pointer that has been freed would be braindead. Otherwise, if one handles the actual pointer value not like a pointer but as any normal integer quantity, then it is perfectly safe. Show me a C compiler that breaks that behaviour, i.e. which breaks the logic of lookup_is_alive(). :> Also, these pointers are always allocated as far as the implementation :> goes because they were allocated through malloc() underneath. The walloc() :> layer on top of that merely redistributes the allocated space among objects, :> but the space is not really freed. None of this memory is really freed. : :A very poor excuse. walloc() is supposed to be transparent to malloc() and :you can compile gtk-gnutella so that it uses malloc() all the time. In :fact for debugging that's highly recommended and by not adhereing to :the standard you make just this more difficult. Again, that would be Crappy, not C. Now if I were to dereference a dangling pointer, that would be a severe bug and it would warrant an immediate fix. Raphael P.S: Actually, that particular logic is older than you would think. And it has been running just fine for the past 4 years in gtk-gnutella already. Just look at dq_alive(). ------------------------------ Message: 5 Date: Tue, 16 Sep 2008 21:43:22 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] [was: DHT uptime.] To: gtk-gnutella-devel@... Message-ID: <20080916194322.GB12286@...> Content-Type: text/plain; charset=utf-8 Raphael Manfredi wrote: > Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel: > :Then what is the purpose of checking 'lid'? It seems pmi->nl can actually > :be a dangling pointer and this is the point of the check. The code could > :be made standard compliant by using pmi->lid instead of pmi->nl because > :'lid' already maps to either 'nl' or NULL. Likewise, 'nl' could be carried > :around as an integer instead of a pointer. Admittedly, a GarbageHashTable > :defeats this by casting it back to a pointer - if you use that directly > :as key - which you don't have to. > > I perfectly know I'm handling a possibly dangling pointer value, and this > is the purpose of the hash table. Just a few mails ago you claimed there is no dangling pointer. I only wrote the lengthy description because you refused to explain the purpose. > I know I could have used an ID in the > table, but as it is a running count it would have meant using a 64-bit > ID and that would imply the use of 64-bit atoms, and I don't want that. I never claimed you don't know what you're doing. Apparently you know quite well that what you do is a hack and an unnecessary one at that. > But let's face it: this code works fine as it is. I don't know that. > An implementation of a > C compiler that would put a level of indirection to all pointer accesses > just to prevent using a pointer that has been freed would be braindead. It's not as braindead as exploits made possible by buffer overflows after 30 years and more of experience with C. Also you seem to think that your idea of why this might be invalid is the only possibility. Don't you think that someone coding for MS-DOS would consider it absurd that you mustn't dereference NULL? Even on some Unix-like systems it might not cause any crash or other problems. In fact, not long ago, many allowed you to map memory at address 0x0. > Otherwise, if one handles the actual pointer value not like a pointer but > as any normal integer quantity, then it is perfectly safe. Yes, once casted to an integer it follows the rules of integer arithmetic instead of pointer arithmetic but the code doesn't do this. > Show me a C compiler that breaks that behaviour, i.e. which breaks the logic > of lookup_is_alive(). The standard permits such a compiler or rather such hardware. That's good enough for me. It wouldn't be hard to modify an existing compiler to catch exactly that i.e., abort the program if you try to load a pointer address that doesn't correspond to allocated memory. > :> Also, these pointers are always allocated as far as the implementation > :> goes because they were allocated through malloc() underneath. The walloc() > :> layer on top of that merely redistributes the allocated space among objects, > :> but the space is not really freed. None of this memory is really freed. > : > :A very poor excuse. walloc() is supposed to be transparent to malloc() and > :you can compile gtk-gnutella so that it uses malloc() all the time. In > :fact for debugging that's highly recommended and by not adhereing to > :the standard you make just this more difficult. > > Again, that would be Crappy, not C. Now if I were to dereference a dangling > pointer, that would be a severe bug and it would warrant an immediate fix. I don't see the problem. On MS-DOS you can dereference any pointer you like. Looks more like cherry-picking to me. > P.S: Actually, that particular logic is older than you would think. Knowing that you base your knowledge of C mainly on deprecated K&R this isn't as surprising to me as you might have expected. > And it has been running just fine for the past 4 years in gtk-gnutella already. > Just look at dq_alive(). Yeah, I already knew I had seen this elsewhere but two wrongs don't make a right. -- Christian ------------------------------ Message: 6 Date: Wed, 17 Sep 2008 08:55:26 -0500 From: Bill Pringlemeir <bpringle@...> Subject: [gtk-gnutella-devel] QRP changes. To: gtk-gnutella-devel@... Message-ID: <87od2mc1wx.fsf@...> Content-Type: text/plain; charset=us-ascii I have committed some changes to core/qrp.c (r15843), Change qrp_can_route to use a function pointer in the routing_table structure. Groups of route decision routines optimize for tables tables from 16k to 2M (corresponding to 14 to 21 bits), in URN and non-URN version are 'templated'. The fixed shift allows compilers to do a much better job of precomputing work. Profiling indicates that the 2^16 and 2^17 are the most common tables sizes (most likely due to lime wire). However, all variants were left. The code size is very small compared to the table sizes. Also, the hottest routines will be cached. It may be more sensible to order the URN and non-URN together (same cache page). However, it seems that URN searches are very rare (not supported by LW?). Alternate data structures could be employed with the function pointer method. Sparse tables could be represented by a trees. Alternate function pointers could decode tables in either array format or tree format; However, the tree structure would trade time for space. My system has a dynamic clock [Intel Prescott]. The rates are 400, 800, 1200, 2400, 3200 MHz. Previously, the CPU would spend time in many of the ranges. With these changes, it is staying in the 400/800 MHz range (also 8deg C cooler). Top measurements are useless with a dynamic clock. 'gprof' also indicates an improvement. However, multiple measurements are probably best for performance improvements. If you have top numbers before/after getting r15843 as an ultra-node. It might be helpful to know if these changes should stay. Although, the changes should be architecture independent. Regards, Bill Pringlemeir. ------------------------------ Message: 7 Date: Wed, 17 Sep 2008 13:31:14 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] QRP changes. To: gtk-gnutella-devel@... Message-ID: <gar0r2$gpm$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Bill Pringlemeir <bpringle@...> from ml.softs.gtk-gnutella.devel: :I have committed some changes to core/qrp.c (r15843), : : Change qrp_can_route to use a function pointer in the routing_table : structure. Groups of route decision routines optimize for tables : tables from 16k to 2M (corresponding to 14 to 21 bits), in URN and : non-URN version are 'templated'. The fixed shift allows compilers : to do a much better job of precomputing work. Thanks, that looks good. I note you used "//" comments. These should be bannished and you should use block comments instead. Raphael ------------------------------ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 25, Issue 3 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
