On Jul 31, 2011, at 8:27 AM, Scott Ribe wrote:
> No, fork copies the entire address space when it is called, but vfork works
> as he described. In neither case will modifications to memory by one process
> by visible by the other.
Oh, hogwash. Of course copy-on-write is a common optimization to
On Jul 31, 2011, at 1:59 AM, vincent habchi wrote:
> Thanks for these precisions. Actually, you’re right with fork (2), but vfork
> (2), AFAIK, does not copy anything; note that I’m aware that vfork usually is
> meant to be immediately followed by exec (3).
No, fork copies the entire address sp
Le 31 juil. 2011 à 09:27, Ron Hunsinger a écrit :
> When a process forks, the child and parent get different virtual memory maps
> that, for the time being, happen to point to the same physical memory pages.
> The sharing is an implementation detail, for optimization. Conceptually, the
> parent
On Jul 31, 2011, at 12:27 AM, Ron Hunsinger wrote:
> The point vincent was making was ...
Sorry for the misattribution. I meant "The point Graham Cox and Scott Ribe were
making was ...".
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please
On Jul 30, 2011, at 11:39 PM, vincent habchi wrote:
>> Memory is "virtual", the addresses you appear to be working with are not
>> real (i.e. they don't refer to the real address of the physical RAM
>> underneath). Instead, a bit of hardware translates these to the real
>> addresses as needed
> Memory is "virtual", the addresses you appear to be working with are not real
> (i.e. they don't refer to the real address of the physical RAM underneath).
> Instead, a bit of hardware translates these to the real addresses as needed
> at some level far below the perception of your program. Yo
On 29/07/2011, at 7:33 AM, Mr. Gecko wrote:
> From my understanding, this should happen when you, for an example, try to
> access the pointer 0x18c95b0 whenever that belongs to another process.
No.
Memory is "virtual", the addresses you appear to be working with are not real
(i.e. they don't
On Jul 28, 2011, at 3:00 PM, Kyle Sluder wrote:
> I'm not sure what your motivation is for calling [self release] here,
> but no code should be doing this.
I disagree. There are a couple of reasons to call this:
- It’s pat of the failure path for -init methods. Before returning nil you need
to
On Jul 28, 2011, at 3:33 PM, Mr. Gecko wrote:
> From my understanding, this should happen when you, for an example, try to
> access the pointer 0x18c95b0 whenever that belongs to another process.
> However, I also thought that the Mac has a copy of memory space for each
> process and therefore
Well, let's think about it. "Instance variables" are only accessible as long
as you have an instance, right? You can't have an instance variable without an
instance. So if you set "self" to nil... then you no longer have an instance.
Thus, you cannot access self's instance variables, because
On Thu, Jul 28, 2011 at 2:45 PM, Mr. Gecko wrote:
> That makes lots of sense, never even expected that to happen. Adding a local
> variable and setting it to the value before releasing it and returning that
> variable fixes the issue. I am still looking to an link to explanation in
> detail as
That makes lots of sense, never even expected that to happen. Adding a local
variable and setting it to the value before releasing it and returning that
variable fixes the issue. I am still looking to an link to explanation in
detail as to why this happens. If it's as I said, then I do not think
It kind of looks like foundCookieJar is an ivar, which means that "return
foundCookieJar" is really going to be "return self->foundCookieJar". Since you
set "self" to "nil", you're trying to dereference a NULL pointer, which is a
great way to crash your app.
HTH,
Dave
On Jul 28, 2011, at 2:3
I am unable to find out as to why I am receiving this problem, I can verify
other parts of the code before it gets to the return and that the object I am
returning does in-fact work as I am able to NSLog it and see the description of
it. The basic idea of this code is to notify other objects to
14 matches
Mail list logo
