David the change set is on ftp://ftp.smalltalkconsulting.com/experimental/JMMRecordMsgSends. 1.cs.zip
If you want to change the logic to invoke what you suggest please do and send me the change set. Having a working example for the Unix VM would be a good thing. The method of interest would be:
Change? Interpreter >>initVmStatsTraceMessageSendLevels vmStatsTraceMessageSendLevels := 0. vmStatsTraceMessageSendStorageFile := 0.
Then consider two sig handlers of your choice. One that tracks the level increment number and increments it by one for each signal and then invokes. Smalltalk setVMStatsTraceMessageSendLevels: theIncrementNumber
The other handler would just reset theIncrementNumber to zero and invoke the setVMStatsTraceMessageSendLevels:
----------
ORIGINAL: *Apologies to people horrified by this piece of code abuses of how self cCode: works and how it interacts with SLANG, however as experimental code things can be a bit hacked*
Interpreter >>initVmStatsTraceMessageSendLevels vmStatsTraceMessageSendLevels := 0. vmStatsTraceMessageSendStorageFile := 0. self cCode: ' { void handleUSR1(int signal); void handleUSR2(int signal);
signal(SIGUSR1, handleUSR1); signal(SIGUSR2, handleUSR2); } } #include <libc.h> #include <signal.h>
void handleUSR1(int signal) { foo->vmStatsTraceMessageSendLevels++; }
void handleUSR2(int signal) { foo->vmStatsTraceMessageSendLevels = 0; if (foo->vmStatsTraceMessageSendStorageFile) fclose(foo->vmStatsTraceMessageSendStorageFile); foo->vmStatsTraceMessageSendStorageFile = 0;
'
On 30-Oct-05, at 10:21 AM, David T. Lewis wrote:
On Sat, Oct 29, 2005 at 09:46:39PM -0700, John M McIntosh wrote:
b) As an extra feature based on conversation with Michael at breakfast this morning you can also do under os-x (unix/darwin) a kill signal to turn recording on.
kill -USR1 19278 {Pick a squeak VM process id}
kill -USR1 19278 {increment the level by one, go to 2} kill -USR1 19278 {increment the level by one, go to 3}
kill -USR2 19278 {turn recording off, and close the file}
Hi John,
Here's one additional suggestion. Rather than dedicating SIGUSR1 and SIGUSR2 to this specific function, you can select what signals to use from the image, and also handle the signals in the image. The OSPP plugin provides the required signal forwarding primitives, so the idea would be to forward SIGUSR1 and SIGUSR2 (or whatever) to semaphores in the image, with processes waiting on the semaphores to do the #setVMStatsTraceMessageSendLevels: calls that control the trace logging.
The reason this is important is that someone else may want to use SIGUSR1 and SIGUSR2 for some other purpose. For example, some pthread libraries on Linux make use of these signals, which would mean that a Linux VM that used pthreads might not work if you steal the signal handlers away from the pthreads library. I think that the svalib on Linux also uses these signals, which would affect somebody who wanted a VM on Linux that ran directly on the VGA display rather than on X window. And who knows about all the sound libraries and so forth. Also, somebody running a Seaside server might want to use SIGUSR1 to signal the server to do an image save (just making this up as a possible example).
Note: I'm afraid that I did not put convenience methods into OSPP for the SIGUSR1 and SIGUSR2 signals (but that's an easy fix), so you would need to specify the actual integer values 10 and 12, as in
startTracingSemaphore := OSProcess accessor forwardSignal: 10. [[startTracingSemaphore wait. (traceLevel < 5) ifTrue: [traceLevel := traceLevel + 1. Smalltalk setVMStatsTraceMessageSendLevels: traceLevel]] repeat] fork
The above is not tested, but you get the idea.
And I should fix up OSP so you can say "OSProcess accessor forwardSigUsr1" instead of "OSProcess accessor forwardSignal: 10".
Dave
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===