What get copied over when exec() is called? - process

Let say we entered wget command. My understanding is that shell calls fork() and a child process is created. At this moment before exec() is called, the child process is identical to the parent process except for things like process ID.
Then when exec() is called, kernel replaces the child process' image with wget's.
But environment variable is not overwritten, so I am confused what are replaced and what are retained from the parent process.

Below is my humble attempt to answer your question. However, I am afraid that the answer can be too overwhelming.
Effect of exec() on process attributes
Also, do visit execve man page.

What you are asking is entirely system specific. For a eunuchs system, there is going to be some area of memory set aside that is not going to be remapped upon exec (). On Linux, I believe this area is at the high end of the user address space.

Related

Create a wxPython app that has only one instance

I would like to create a wxPython app such that:
If I run a second instance of that app (e.g., call the Python script from the shell a second time), no new instance should be created.
Instead, the toplevel frame of the already running instance should be raised and focussed.
The first point can be easily implemented by wx.SingleInstanceChecker (see the example code there), but at least the example code only gives a way for making the second instance of the app abort, but not raise the existing app's main frame.
I am using wxPython-Phoenix with Python 3.
Claritication: I would much prefer an out-of-the-box solution like wx.SingleInstanceChecker (that is, not implement my own locking and IPC solution).
You can use any kind of IPC to send a message asking the other program to do whatever needs to be done (just raise its top level window or maybe handle the command line options passed to the second instance). In C++ there are wxConnection and the related wxServer and wxClient classes that can be used for this, but I'm not sure if they're wrapped by wxPython -- however you could use any Python IPC module instead, if they aren't.
As has been pointed out, the "correct" way to do this is IPC because you have a new process that is supposed to affect a change (raise and focus) in another process.
What you seem to want is to take advantage of the IPC channel that wx.SingleInstanceChecker is already using to do your work. Unfortunately, you can't. That class is implemented in the wxWidgets c++ code and therefore there are no Python bindings to the internal workings of the class.
However, you can probably abuse wx.SingleInstanceChecker to do what you want. In your program, you can set up a timer at some rapid interval (say, 250ms) that will constantly check IsAnotherRunning() from your main process. Therefore, when your second process starts up, the first will notice and can raise itself to the front. You would just have to wait for a little bit in the secondary process before it exits, to give the first time to notice.

Labview Program changes behavior after looking at (not changing) the Block Diagram

My Labview Program works like a charm, until I look at the Block Diagram. No changes are made. I do not Save. Just Ctrl+E and then Ctrl+R.
Now it does not work properly. Only a Restart of Labview fixes the problem.
My Program controls two Scanner arrays for Laser Cutting simultaneously. To force parallel working, I use the Error handler and loops that wait for a signal from the Scanner. But suddenly some loops run more often than they should.
What does majorly happen in Labview when I open the Block diagram that messes with my code?
Edit:
Its hard to tell what is happening without violating my non-disclosure agreement.
I'm controlling two independent mirror-Arrays for Laser Cutting. While one is running one Cutting-Job, the other is supposed to run the other Jobs. Just very fast. When the first is finished they meet at the same position and run the same geometry at the same slow speed. The jobs are provided as *.XML and stored as .net Objects. The device only runs the most recent job and overwrites it when getting a new one.
I can check if a job is still running. While this is true I run a while loop for the other jobs. Now this loop runs a few times too often and even ignores WAIT-blocks to a degree. Also it skips the part where it reads the XML job file, changes the speed part back to fast again and saves it. It only runs one time fast.
#Joe: No it does not. It only runs once well. afterwards it does not.
Youtube links
The way it is supposed to move
The wrong way
There is exactly one thing I can think of that changes solely by opening the block diagram.
When the block diagram opens, any commented-out or unreachable-code-compiler-eliminated sections of code will load their subVIs. If one of those commented out sections of code were somehow interfere with your running code, you might have an issue.
There are only two ways I know of for that to interfere... both of them are fairly improbable.
a) You have some sort of "check for all VIs in memory" or "check for all types in memory" that you're using as a plug-in system. When the commented-out sections load, that would change the VIs in memory. Such systems are not uncommon when parsing XML, so maybe.
b) You are using Run VI method for some dynamically invoked VI to execute as a top-level VI, but by loading the diagram, it discovers that it is a subVI of your current program. A VI cannot simultaneously be top-level and a subVI, so the call to Run VI returns an error.
That's it. I can't think of anything else. Both ideas seem unlikely, but given your claim and a lack of a block diagram, I figured I'd post it as a hypothesis.
In the improbable case someone has a similar problem. The problem was a xml file that was read during run time. Sometimes multiple instances tried to access it and this produced the error.
Quick point to check: are Debug and "retain data in wires" disabled? While it may not change the computations, but it may certainly change the timing of very tight loops, and that was one of the unexpected program behaviors, OP was referring to.

Labview 2012 Passing Dynamic data into/out of a while loop

I'm trying to pass data which is continuously changed from the inside of one While loop to the inside of another While loop of a sub-vi. The main program on the left is constantly reading new data and the program on the right is adding 1 to the new value. My issue is that I cannot input new values to a While loop which is already running and thus my sub-vi is never updated. I've tried a global variable ("write" from the main program control and then "read" into the sub-vi) but that doesn't work either (same result as if the main were just passing data into the sub).
I apparently don't have enough reputation to post a picture of my program but I'm basically trying to run parallel loops (almost inside each other). Can anyone lend me an experienced hand?
The most common problem with while loops are based on lack of knowledge how exactly does the while loop work in LabVIEW.
First of all the information will be given outside the loop only if the condition terminal (right down corner of the loop) will be flagged as true.
If you want to pass the data earlier (while the loop is running) you have to choose easiest option:
Use queue (is the most common and well working). I can elaborate how this one work in practise if you want, or just try to run an example from LabVIEW help.
local/shared variables - you can define in your own library variables and pass the data by READ/WRITE option.
Please try to upload some documentation to an external server (as you are blocked here), and post a link, and then I could help you with a specific example.
HelpĀ»Find Examples. Search for "queue". Pick out an example with parallel loops.
You might want to look into Queues or Notifiers as means of passing data between running loops.

Is there a way to ensure that a kernel module runs in a specific process context?

Basically, how can I make sure that in my module, a specific process is current. I've looked at kick_process, but I'm not sure how to have my module execute in the context of that process once kicking it into kernel mode.
I found this related question, but it has no replies. I believe an answer to my question could help that asker as well.
Note: I am aware that if I want the task_struct of a process, I can look it up. I'm interested in running in a specific context since I want to call functions that reference current.
Best way i have found to do anything in the context of a particular process in the kernel, is to sleep in process context(wait_* family of functions) and wake up that thread and do whatever needs to be done in that context. This would ofcourse mean you would have to have the application call into the kernel via IOCTL or something and sleep on that thread and wake it up whenever you need to do something. This seems to be a very widely used and popular mechanism.

Deadlock using third party Ingear.Net .dll?

I am using a .dll from Ingeardrivers.com. I realize this question would more appropriately be asked on that site and have posted to there as well but more people on here makes my chances of it getting answered better.
I am a novice programmer and this is my first experience with threading. Basically I have two main loops in my program, and when I run each loop as the 'main thread' by itself - they both work fine individually. The problem is when I am starting two threads and running the main loop inside these threads, at some point in the loop they both are trying to use the Ingear.net dll and when one loop already has created an instance of the class, the second loop just sits on the constructor and doesn't do anything.
Does anyone have any suggestions on how to resolve?
I'd recommend firstly that you check with the vendor to see if the library is thread safe.
But in the mean time you could try creating a single instance of the class and passing it to your two threads/loops as part of the constructor (or setting a property with it).
It'll most likely not work, but you won't know until you try.
The add-on is thread safe -
I was manually disconnecting the controller each time via 'controllername.disconnect()'
For some reason this didn't actually close the connection and I was maxed out on CIP connections. When I removed that, the controller somehow knew to disconnect by itself.
Strange but it works.