Copy-On-Write : What status after father and son modify the page? - memory

When you fork a process, at the beggining, father and son share the same memory page. But if one of them write on this page, it is duplicated so that the first one is not affected by this change. That's roughly what is called Copy-on-Write.
My question is : What happens if we fork() a process, then the child modify the page: the page is duplicate once, but after that, the father ALSO modify the page. Is the page duplicated again? Does the father "know" that is only son already duplicated?
Thank you in advance for your help.

(Generic at the risk of oversimplification -- IE how it COULD work)
Parent process has Virtual Page 10 as readwrite physical page 1000.
Parent process has Virtual Page 11 as readwrite physical page 1001.
Parent forks child.
Parent process has Virtual Page 10 as readonly physical page 1000.
Parent process has Virtual Page 11 as readonly physical page 1001.
Child process has Virtual Page 10 as readonly physical page 1000.
Child process has Virtual Page 11 as readonly physical page 1001.
Parent write to Virtual Page 10.
Triggers a protection fault.
OS detects it is a copy on write page
Copies physical page 1000 to 1002
Decrements reference count to physical page 1000
restarts instruction
Parent process has Virtual Page 10 as readwrite physical page 1002.
Parent process has Virtual Page 11 as readonly physical page 1001.
Child process has Virtual Page 10 as readonly physical page 1000.
Child process has Virtual Page 11 as readonly physical page 1001.
Child write to virtual page 11
Triggers a protection fault.
OS detects it is a copy on write page
Copies physical page 1001 to 1003
Decrements reference count to physical page 1001
restarts instruction
Parent process has Virtual Page 10 as readwrite physical page 1002.
Parent process has Virtual Page 11 as readonly physical page 1001.
Child process has Virtual Page 10 as readonly physical page 1000.
Child process has Virtual Page 11 as readwrite physical page 1003.
Parent writes to virtual page 11
Triggers a protection fault.
OS detects it is a copy on write page AND that the reference count is 1.
OS changes the page to readwrite
restarts instruction
Parent process has Virtual Page 10 as readwrite physical page 1002.
Parent process has Virtual Page 11 as readwrite physical page 1001.
Child process has Virtual Page 10 as readonly physical page 1000.
Child process has Virtual Page 11 as readwrite physical page 1003.

There are n processes having access to a copy-on-write page, with n ≥ 2. If one process writes, the page is copied and becomes a normal page for that process. The original page is now shared n-1 times only; if n = 1 then it becomes a normal page as well. There would be no point in making two copies.

Related

Check state in Virtual TreeView seems not virtual

I am using Virtual TreeView. In my understanding, since the whole treeview is virtual, the node properties(including the check state) are set on request(such as on a OnData event handler) instead of storing together with the node, since the node is total virtual. However, it seems that Virtual TreeView will store the check state of the node together with the node, instead of obtain from external data source and set on request.
Why?
Use the OnBeforeGetCheckState event to handle this in a more virtual manner. The OnChecking and OnChecked event might also be helpful.

How publish object by Stream to a sibling component which is not yet created?

I have one view which loads some data and needs to pass it to a sibling view. I'm trying to use shared injectable service + Stream add/listen.
I have read https://angular.io/guide/component-interaction#parent-and-children-communicate-via-a-service and many other similar questions but my case is different.
In my case, sibling is not created when I do service.streamController.add and thus, nothing happens when I navigate to sibling, it has listen method but I guess it cannot catch smth published before component started.

Entity Framework 4 error: An entity object cannot be referenced by multiple instances of IEntityChangeTracker

I am using EF4 for the first time and have adopted a strategy of a UnitofWork (DataContext) per View. However, I am having issues and seek advice.
I have a window that displays a list of workstations, when I click the edit button I have another window that displays the selected workstation for edit.
The list view and the edit view use their own UnitOfWork, the selected workstation is passed through to the edit view, however when I try to save the workstation on the edit view I get the following;
An entity object cannot be referenced by multiple instances of IEntityChangeTracker
I know that this is because the workstation object that I passed through to the edit view has a data context associated with it.
How should i deal with this??
Three choices:
The edit view can re-select the workstation from its own context based on the PK of the entity from the other view.
You can Detach the workstation from the list view and then Attach it to the edit view.
If the list view is read only, you can use MergeOption.NoTracking to prevent the context from tracking changes at all. You still would need to attach it to the edit context.

bring the last loaded controls back when i restart the machine

I am working in video application in my application am using many controls for user friendly first i will Load the base from only after that i ll load the other controls based on user need.... here my need is if user load ten controls in this case if he shutdown the machine means when he restart the machine i need to bring the all controls back what he was load the controls before he shutdown. thanks in advance
is there is any possible to achive this without store the current control set, and positions etc..
You need to look at something like
Form and Control Position and Size
Utility
Save and restore Form position and
layout with this component
Basically what it boils down to, is that you need a way to store the current control set, and positions (possibly values too) to some sort of storage (XML file, Registry, Database) when the user exits your form/application.
Then once they reopen the form/application, you need to retrieve these settings for the given user (if any is available) and restore the form/application to that state.
How about making extension methods to Control class?
(Actually, appropriate .NET abstract base class, a sub-class of Control class, depending on UI. Do you use Windows Forms or XAML or ASP.NET?)
Something like:
public static class MyPositionExtensions{
public static void SaveState(this Control c){ /* Save position to xml-file */ }
public static void RestoreState(this Control c){ /* Load from xml-file */ }
}
Then in your closing just loop like
foreach(var c in MyControls)c.SaveState();
and opening like
foreach(var c in MyControls)c.RestoreState();

ASP.NET MVC - For loop inside RenderPartial or Outside RenderPartial

Which one has the best performance. I have a list array that contains a list of articles. When I list the articles I have a RenderPartial that displays just one article and the parent page goes through a loop of all the articles. The Renderpatial is inside the parentpage loop. What is the best way to go about this?
Loop inside the partial view if you can. Each time you call RenderPartial, the following things happen (courtesy of the MVC source files):
RenderPartial calls RenderPartialInternal
RenderPartialInternal creates a new ViewDataDictionary and a new ViewContext
RenderPartialInternal calls FindPartialView to locate and instantiate a view
FindPartialView searches all registered view engines (normally just one) for the view, using the controller context and view name as keys. Each view engine searches for the view in all the paths it supports, e.g. Views/controller/view.aspx, Views/controllers/view.ascx, Views/Shared/view.aspx, etc. Views can be returned from a memory cache to accelerate this step
The view's Render method is called. I lost track of the inner workings of the Render method of the standard WebFormView at 13 levels down the stack. Render constructs a large numbers of context objects the inner view needs, checks for permissions to run the view, hooks up events for any server controls, re-inspects the Request object to decide what more it needs to do, and so on. After actually rendering the view, it unwinds the context it has created.
Overall, none of these is too bad. It all happens inside the machine's CPU and RAM, which is more than can be said for typical database access that happens in the controller. The process needs to go out to disk only the first time the view is loaded (that can be slow, however; files have to be searched and the view has to be compiled). ASP.NET MVC had to optimize the view rendering process to maintain a high level of performance.
Still, this is quite a bit, and if you can avoid running it multiple times in one request, it will help improve the action method's response times.
One thing that will improve performance of your views by several times
is to set the Debug=false in your web.config (i.e. deploy in Release mode)
In this case MVC engine will cache all views (including partials) and will not try to resolve their location and load them on every attempt to use them.

Resources