graeme@praxis.co.uk (Graeme Cutler) (03/04/91)
I would like to be able to start different copies of the same process from threads in the same process. The process would effectively be a timer process which will clear a semaphore if the timer process times out on a DosSleep. However if the thread that started the timer process so wished I want the ability to kill the thread specific timer process. So I thought that any thread would call a function something like create_timer passing in a number of arguements. The function call would issue DosExecPgm and start a timer process, timer.exe. The function call would return the process id so that if the calling thread so wished it would be able to issue a DosKillProcess using the PID of the process it started. But I have (apparently?) misunderstood the RESULTCODES structure returned from issuing the DosExecPgm. I assumed that it returned the PID of the newly started process. Does not appear to(?) ;-( Now I have a problem. How can a thread issue a DosKillProcess and kill off its timer process? Can I use DosGetPIDD or DosGetPID ? sensibly? Especially as it will be used by threads in the same process trying to get info on their timer processes. A grotty way to resolve the problem would be to have unique timer process names, but what a dirty way of doing it. Unix handles this sort of thing much better ;-). Any suggestions of there? Graeme Cutler
ballard@cheddar.ucs.ubc.ca (Alan Ballard) (03/06/91)
In article <1991Mar4.151549.10409@praxis.co.uk> graeme@praxis.co.uk (Graeme Cutler) writes: >... The function call would issue >DosExecPgm and start a timer process, timer.exe. > >The function call would return the process id so that if the calling >thread so wished it would be able to issue a DosKillProcess using the PID >of the process it started. > >But I have (apparently?) misunderstood the RESULTCODES structure returned >from issuing the DosExecPgm. I assumed that it returned the PID of the >newly started process. Does not appear to(?) ;-( > DosExecPgm DOES return the PID, as long as the fExecFlags parameter is set to EXEC_ASYNC or EXEC_ASYNCRESULT. I've used it in the way you describe (for later killing the process) without any problem. Alan Ballard | Internet: ballard@ucs.ubc.ca University Computing Services | Bitnet: USERAB1@UBCMTSG University of British Columbia | Phone: 604-228-3074 Vancouver B.C. Canada V6R 1W5 | Fax: 604-228-5116
towfiq@FTP.COM (Mark Towfiq) (03/19/91)
In article <1991Mar4.151549.10409@praxis.co.uk> graeme@praxis.co.uk (Graeme Cutler) writes: [description of multiple threads starting timer processes, and problems with killing them, deleted] A grotty way to resolve the problem would be to have unique timer process names, but what a dirty way of doing it. Unix handles this sort of thing much better ;-). Any suggestions of there? When I first started programming in OS/2, I did something similar to what you are doing, and wanted to start processes left and right to perform certain tasks. Perhaps it was because of my familiarity with the UNIX fork()-style of doing things. Well, in the past couple of years, I have realized that threads are threads, and semaphores are semaphores, and they should be used. I am sure there is a simple solution to your RESULTCODES problem (maybe you are calling DosExecPgm() with the wrong flags), but I would suggest you re-do the timing architecture. You haven't given many details, but I assume that timer.exe just takes an arg and waits for a period before exiting--whatever it is, it could become a thread. I would suggest using a ram semaphore local to each thread (i.e. on the stack) with a timeout value to keep time. This eats much less memory, and has the advantage of not starting many small processes. If your architecture is different from what I assumed, feel free to clarify. Hope this helps, Mark -- Mark Towfiq, FTP Software, Inc. towfiq@FTP.COM Work No.: +1 617 246 0900 Home No.: +1 617 488 2818 "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah