Excerpts from Adam Chlipala's message of Wed Dec 01 15:50:26 +0100 2010: > Yes and no. The global functions will accomplish what you want. > However, pointers allocated by uw_malloc() should not be referenced > across requests. You should use regular malloc() for such memory. Note > that uw_set_global() allows you to specify a function to call to free > the value you set; for anything that lasts across requests, you do need > to start thinking about explicit freeing.
What does "request" mean exactly? The user (browser) issues a request. Then urweb will run code and maybe retry. Therefore its still the same request. 1) request made 2) urweb runs code, C is calling abort (retry) 3) urweb reruns code - this time there is success. Now will pointers be freed after 2) or after 3)? >From reading "request" in docs I assumed its always freed after 3). So you should be more explicit. Probably its best to clarify this in the description of uw_malloc. Between 2) and 3) heap may increase. But when will the old heap be freed? if it was freed after 3) you could use uw_malloc for keeping the cache data (improving speed) > Even some of the already-implemented protocols will ignore stderr > output. There is some generic logging stuff implemented now, but only > for use by the protocols, as it isn't exposed via contexts. This seems > like a reasonable change to make, and I'll look into it if you open a > Mantis issue. done. I think its not important to have the perfect logging implementation. I think its important to add function which can be used so that the implementation can be made perfect without grepping for printf or cout << .. << statements. Marc Weber _______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
