reference-counting

When I create an object and check its retain count, I get 1 as expected. When I release the object and then check the retain count again, it is still 1. Shouldn't the object be deallocated, and the retain count 0? NSMutableString *str=[[NSMutableString alloc] initWithString:@"hello"]; NSLog(@"reference count is %i",[str retainCount]); [str release]; NSLog(@"reference count is %i",[str retainCount]); I do see 0 for the retain count if I set str to nil first. Why is that? Don't use retainCount , it doesn't do what you expect in most cases. Your second NSLog is accessing deallocated memory as an

Given the following (manual reference counting): void (^block)(void) = ^ { NSLog(@"wuttup"); } void (^async_block)(void) = ^ { block(); } dispatch_async(dispatch_get_main_queue(), async_block); Will "block" be copied rather than thrown off the stack and destroyed? I believe, the answer is Yes. The outer block will be asynchronously dispatched which causes the runtime to make a copy on the heap for this block. And as shown below, and described in the Block Implementation Specification - Clang 3.4 Documentation , the inner block's imported variables are also copied to the heap. In the OP's

Whenever I called my function, memory usage is increased around +10M per call, so I think there is some memory leak here. .... PyObject *pair = PyTuple_New(2), *item = PyList_New(0); PyTuple_SetItem(pair, 0, PyInt_FromLong(v[j])); if(v[j] != DISTANCE_MAX && (p[j] || d[0][j])){ jp=j; while(jp!=istart) { PyList_Append(item, PyInt_FromLong(jp)); jp=p[jp]; } PyList_Append(item, PyInt_FromLong(jp)); PyList_Reverse(item); } PyTuple_SetItem(pair, 1, item); return pair; .... When I read document , some calls like void bug(PyObject *list) { PyObject *item = PyList_GetItem(list, 0); PyList_SetItem(list,

I have the following code which uses both Rc and Box ; what is the difference between those? Which one is better? use std::rc::Rc; fn main() { let a = Box::new(1); let a1 = &a; let a2 = &a; let b = Rc::new(1); let b1 = b.clone(); let b2 = b.clone(); println!("{} {}", a1, a2); println!("{} {}", b1, b2); } playground link Rc provides shared ownership so by default its contents can't be mutated, while Box provides exclusive ownership and thus mutation is allowed: use std::rc::Rc; fn main() { let mut a = Box::new(1); let mut b = Rc::new(1); *a = 2; // works *b = 2; // doesn't } In addition Rc

So I was reading this article about an attempt to remove the global interpreter lock (GIL) from the Python interpreter to improve multithreading performance and saw something interesting. It turns out that one of the places where removing the GIL actually made things worse was in memory management: With free-threading, reference counting operations lose their thread-safety. Thus, the patch introduces a global reference-counting mutex lock along with atomic operations for updating the count. On Unix, locking is implemented using a standard pthread_mutex_t lock (wrapped inside a PyMutex

The standard convention in the Python C-API is that functions do not steal references from input arguments (that are objects) return values and output arguments (that are objects) own a reference Most functions in the Python C-API follow this convention. However, there are some exceptions. I have come across the following: Functions that steal a reference from an input argument PyModule_AddObject Functions with return values or output arguments that borrow a reference PyErr_Occurred PyTuple_GetItem PyTuple_GETITEM PyDict_GetItem PyDict_GetItemString PyDict_Next Is there a comprehensive list of