In of the places I have written itcl code in a thread that kills excel
method Kill_XL {} {
thread::create {
set rc [catch {exec taskkill /t /f /im Excel*} output]
}
sleep 5
}
After that, for several different wish shells the following command invokes Excel App but I can see it immediately exiting in task manager
(shh..) 2 % ::tcom::ref createobject Excel.Application
::tcom::handle0x027CE918
(shh..) 3 % ::tcom::ref createobject Excel.Application
::tcom::handle0x027CE918
The above is repeated for a several wish shells (each invoked after closing the previous wish shell).
On running any command, the error appears as:
"invalid command name ::tcom::handle0x027CE918"
But the following code works and opens up a Word application without a problem
(shh..) 4 % ::tcom::ref createobject Word.Application
::tcom::handle0x027CE918
After waiting for a long time (15-20 minutes), I restarted the wish shell and was able to run (without problem) the following code:
(shh..) 8 % set x [::tcom::ref createobject Excel.Application]
::tcom::handle0x0272EB58
(shh..) 9 % $x Visible 1
And a different error message this time after killing excel
(shh..) 10 % thread::create {
set rc [catch {exec taskkill /t /f /im Excel*} output]
}
tid00004658
(shh..) 11 % $x Visible 0
0x800706ba {The RPC server is unavailable.}
And then is starts all over again:
(shh..) 20 % ::tcom::ref createobject Excel.Application
::tcom::handle0x0272EB58
(shh..) 21 %
(shh..) 21 % ::tcom::handle0x0272EB58 Visible 1
invalid command name "::tcom::handle0x0272EB58"
Is the threaded kill causing problems - I am always sleeping 5 seconds to ensure the kill is successful.
Or is it some other (known) issue with tcom-Excel?
Also, giving the same app handles all the time
(shh..) 30 % foreach x {. .} {puts [::tcom::ref createobject Excel.Application]}
::tcom::handle0x0272EB58
::tcom::handle0x0272EB58
Could this be a cleanup issue with unreleased tcom objects - does it not clenaup automatically on killing the excel process associated?
This was some problem with the OS - doesn't get repeated after OS was re-imaged.
Related
Here is my code:
-module(cooperate).
-compile(export_all).
producer(_Pid, 0) ->
done;
producer(Pid, N) ->
io:format("process ~p producing ~p~n", [Pid, rand:uniform(N)]),
producer(Pid, N-1).
start() ->
spawn(cooperate, producer, [rand:uniform(7), 7]).
Results:
{ok,cooperate}
2> cooperate:start().
process 2 producing 6
<0.88.0>
process 2 producing 3
process 2 producing 4
process 2 producing 4
process 2 producing 1
process 2 producing 2
process 2 producing 1
3>
Expecting:
process <0.88.0> producing 6
process <0.88.0> producing 3
process <0.88.0> producing 4
process <0.88.0> producing 4
process <0.88.0> producing 1
process <0.88.0> producing 2
process <0.88.0> producing 1
What should I do if I want to print <0.88.0> between process and producing instead of 2?
I tried something like pid_to_list, ~p, etc
The first argument of your producer function is named Pid, yet you never pass any pid as the first argument of this function. The argumenr when the function is first called is rand:uniform(7), which in your test happen to return 2.
If you want your function to print the pid of the process you spawned, the best way would be to get rid of the first argument, and use self() instead.
In Programming Erlang by Joe Armstrong, Chapter 12, "Making a Set of Processes That All Die Together", the following code is given:
% (Some variables are renamed and comments added for extra clarity)
start(WorkerFuns) ->
spawn(fun() ->
% Parent process
[spawn_link(WorkerFun) || WorkerFun <- WorkerFuns],
receive
after infinity -> true
end
end).
The resulting processes are linked as such:
+- parent -+
/ | \
/ | \
worker1 worker2 .. workerN
If a worker crashes, then the parent crashes, and then the remaining workers crash as well. However, if all of the workers exit normally, then the parent process lives forever, albeit in a suspended state.
While Erlang processes are supposed to be cheap, if start/1 is called many times in a long-running service, one process—the parent—appears to be "leaked" every time all workers exit normally.
Is this ever a problem in practice? And is the extra code to properly account for when all workers exit normally (see below), worth it?
start(WorkerFuns) ->
spawn(fun() ->
% Parent process
process_flag(trap_exit, true),
[spawn_link(WorkerFun) || WorkerFun <- WorkerFuns],
parent_loop(length(WorkerFuns))
end).
parent_loop(0) ->
% All workers exited normally
true;
parent_loop(RemainingWorkers) ->
receive
{'EXIT', _WorkerPid, normal} ->
parent_loop(RemainingWorkers - 1);
{'EXIT', _WorkerPid, CrashReason} ->
exit(CrashReason)
end.
Your analysis is correct. The code as given does not account for normal termination of the workers and will leave a dangling process. The space leak will be about 2 kb per invocation, so in a large system you're not likely to notice it unless you call start/1 a thousand times or more, but for a system expected to run "forever" you should definitely add the extra code.
On Mac OS using mono, if I compile and profile the program below, I get the following results:
% fsharpc --nologo -g foo.fs -o foo.exe
% mono --profile=default:stat foo.exe
...
Statistical samples summary
Sample type: cycles
Unmanaged hits: 336 (49.1%)
Managed hits: 349 (50.9%)
Unresolved hits: 1 ( 0.1%)
Hits % Method name
154 22.48 Microsoft.FSharp.Collections.SetTreeModule:height ...
105 15.33 semaphore_wait_trap
74 10.80 Microsoft.FSharp.Collections.SetTreeModule:add ...
...
Note the second entry, semaphore_wait_trap.
Here is the program:
[<EntryPoint>]
let main args =
let s = seq { 1..1000000 } |> Set.ofSeq
s |> Seq.iter (fun _ -> ())
0
I looked in the source for the Set module, but I didn't find any (obvious) locking.
Is my single-threaded program really spending 15% of its execution time messing with semaphores? If it is, can I make it not do that and get a performance boost?
According to Instruments, it's sgen/gc calling semaphore_wait_trap:
Sgen is documented as stopping all other threads while it collects:
Before doing a collection (minor or major), the collector must stop
all running threads so that it can have a stable view of the current
state of the heap, without the other threads changing it
In other words, when the code is trying to allocate memory and a GC is required, the time it takes shows up under semaphore_wait_trap since that's your application thread. I suspect the mono profiler doesn't profile the gc thread itself so you don't see the time in the collection code.
The germane output then is really the GC summary:
GC summary
GC resizes: 0
Max heap size: 0
Object moves: 1002691
Gen0 collections: 123, max time: 14187us, total time: 354803us, average: 2884us
Gen1 collections: 3, max time: 41336us, total time: 60281us, average: 20093us
If you want your code to run faster, don't collect as often.
Understanding the actual cost of collection can be done through dtrace since sgen has dtrace probes.
I received such message in erlang condose at first#localhost node
=ERROR REPORT==== 1-Jan-2011::23:19:28 ===
** Node 'second#localhost' not responding **
** Removing (timedout) connection **
My question is - what is timeout in this case? How much time before causes this event?
Howto prevent this "horror"? I can restore\recover to normal work only by restart node...
But what is the right way?
Thank you, and Happy New Year!
Grepping for the not responding string in the Erlang source code, you can see how the message is generated in the dist_util module in the kernel application (con_loop function).
{error, not_responding} ->
error_msg("** Node ~p not responding **~n"
"** Removing (timedout) connection **~n",
[Node]),
Within the module, the following documentation is present, explaining the logic behind ticks and not responding nodes:
%%
%% Send a TICK to the other side.
%%
%% This will happen every 15 seconds (by default)
%% The idea here is that every 15 secs, we write a little
%% something on the connection if we haven't written anything for
%% the last 15 secs.
%% This will ensure that nodes that are not responding due to
%% hardware errors (Or being suspended by means of ^Z) will
%% be considered to be down. If we do not want to have this
%% we must start the net_kernel (in erlang) without its
%% ticker process, In that case this code will never run
%% And then every 60 seconds we also check the connection and
%% close it if we havn't received anything on it for the
%% last 60 secs. If ticked == tick we havn't received anything
%% on the connection the last 60 secs.
%% The detection time interval is thus, by default, 45s < DT < 75s
%% A HIDDEN node is always (if not a pending write) ticked if
%% we haven't read anything as a hidden node only ticks when it receives
%% a TICK !!
Hope this helps a bit.
I am interested in bench-marking different parts of my program for speed. I having tried using info(statistics) and erlang:now()
I need to know down to the microsecond what the average speed is. I don't know why I am having trouble with a script I wrote.
It should be able to start anywhere and end anywhere. I ran into a problem when I tried starting it on a process that may be running up to four times in parallel.
Is there anyone who already has a solution to this issue?
EDIT:
Willing to give a bounty if someone can provide a script to do it. It needs to spawn though multiple process'. I cannot accept a function like timer.. at least in the implementations I have seen. IT only traverses one process and even then some major editing is necessary for a full test of a full program. Hope I made it clear enough.
Here's how to use eprof, likely the easiest solution for you:
First you need to start it, like most applications out there:
23> eprof:start().
{ok,<0.95.0>}
Eprof supports two profiling mode. You can call it and ask to profile a certain function, but we can't use that because other processes will mess everything up. We need to manually start it profiling and tell it when to stop (this is why you won't have an easy script, by the way).
24> eprof:start_profiling([self()]).
profiling
This tells eprof to profile everything that will be run and spawned from the shell. New processes will be included here. I will run some arbitrary multiprocessing function I have, which spawns about 4 processes communicating with each other for a few seconds:
25> trade_calls:main_ab().
Spawned Carl: <0.99.0>
Spawned Jim: <0.101.0>
<0.100.0>
Jim: asking user <0.99.0> for a trade
Carl: <0.101.0> asked for a trade negotiation
Carl: accepting negotiation
Jim: starting negotiation
... <snip> ...
We can now tell eprof to stop profiling once the function is done running.
26> eprof:stop_profiling().
profiling_stopped
And we want the logs. Eprof will print them to screen by default. You can ask it to also log to a file with eprof:log(File). Then you can tell it to analyze the results. We tell it to collapse the run time from all processes into a single table with the option total (see the manual for more options):
27> eprof:analyze(total).
FUNCTION CALLS % TIME [uS / CALLS]
-------- ----- --- ---- [----------]
io:o_request/3 46 0.00 0 [ 0.00]
io:columns/0 2 0.00 0 [ 0.00]
io:columns/1 2 0.00 0 [ 0.00]
io:format/1 4 0.00 0 [ 0.00]
io:format/2 46 0.00 0 [ 0.00]
io:request/2 48 0.00 0 [ 0.00]
...
erlang:atom_to_list/1 5 0.00 0 [ 0.00]
io:format/3 46 16.67 1000 [ 21.74]
erl_eval:bindings/1 4 16.67 1000 [ 250.00]
dict:store_bkt_val/3 400 16.67 1000 [ 2.50]
dict:store/3 114 50.00 3000 [ 26.32]
And you can see that most of the time (50%) is spent in dict:store/3. 16.67% is taken in outputting the result, another 16.67% is taken by erl_eval (this is why you get by running short functions in the shell -- parsing them becomes longer than running them).
You can then start going from there. That's the basics of profiling run times with Erlang. Handle with care, eprof can be quite a load on a production system or for functions that run for too long. Especially on a production system.
You can use eprof or fprof.
The normal way to do this is with timer:tc. Here is a good explanation.
I can recommend you this tool: https://github.com/virtan/eep
You will get something like this https://raw.github.com/virtan/eep/master/doc/sshot1.png as a result.
Step by step instruction for profiling all processes on running system:
On target system:
1> eep:start_file_tracing("file_name"), timer:sleep(20000), eep:stop_tracing().
$ scp -C $PWD/file_name.trace desktop:
On desktop:
1> eep:convert_tracing("file_name").
$ kcachegrind callgrind.out.file_name