[VW 7.1] THAPI: What happens if "DLL" function calls sleep()?
Locked
[VW 7.1] THAPI: What happens if "DLL" function calls sleep()?
 
|
All, I have a question regarding the use of _threaded calls to a subclass of
ExternalInterface. My image (VW 7.1) links to a shared library, and the image runs on Solaris 9. The shared library was written by my company. I am invoking the C functions of this shared library using native OS threads; i.e., I invoke the functions with the _threaded option. One of the shared library functions I invoke performs sleep(..) to sleep for a second. The sleep() invocation is in a polling loop. Questions: 1. Is it possible for the sleep() invocation to "wake up" the object engine and let it run normal Smalltalk processes and/or other _threaded calls? Chris |
RE: [VW 7.1] THAPI: What happens if "DLL" function calls sleep()?
|
|
> 1. Is it possible for the sleep() invocation to "wake up" the
> object engine and let it run normal Smalltalk processes and/or > other _threaded calls? The object engine does sleep ocasionally, when it gets a chance, as when there are no more pending operations, afik. But your question seems to indicate that the OE goes to sleep after making a threaded DLLCC callout, and I don't think this is the case as a general rule. If this is happening, there may be something out of whack. However, the OE does sleep sometimes, and maybe you want your thread to wake it up for some reason. Maybe an event could be generated, like a signal of some sort, and sent to the OE. But that might not be very efficient. Presumably, a simple callback could wake it up, for example. - Dave W > -----Original Message----- > From: Chris Winemiller [mailto:[hidden email]] > Sent: Monday, March 20, 2006 2:43 PM > To: [hidden email] > Subject: [VW 7.1] THAPI: What happens if "DLL" function calls sleep()? > > > All, I have a question regarding the use of _threaded calls > to a subclass of > ExternalInterface. > > My image (VW 7.1) links to a shared library, and the image > runs on Solaris 9. > The shared library was written by my company. > > I am invoking the C functions of this shared library using > native OS threads; > i.e., I invoke the functions with the _threaded option. > > One of the shared library functions I invoke performs > sleep(..) to sleep for a > second. The sleep() invocation is in a polling loop. > > Questions: > > 1. Is it possible for the sleep() invocation to "wake up" the > object engine > and let it run normal Smalltalk processes and/or other > _threaded calls? > > Chris > > |
Re: [VW 7.1] THAPI: What happens if "DLL" function calls sleep()?
|
|
In reply to this post by Chris Winemiller
On Mar 20, 2006, at 14:42, Chris Winemiller wrote: > All, I have a question regarding the use of _threaded calls to a > subclass of ExternalInterface. > > My image (VW 7.1) links to a shared library, and the image runs on > Solaris 9. The shared library was written by my company. > > I am invoking the C functions of this shared library using native > OS threads; i.e., I invoke the functions with the _threaded option. > > One of the shared library functions I invoke performs sleep(..) to > sleep for a second. The sleep() invocation is in a polling loop. > > Questions: > > 1. Is it possible for the sleep() invocation to "wake up" the > object engine and let it run normal Smalltalk processes and/or > other _threaded calls? The smalltalk execution thread is a single native os thread that executes all Smalltalk code. It will run as long as there are any Smalltalk processes that have code to execute. If not, it goes to sleep. It will sleep until something like SIGIO or SIGALRM or any of those happen. The right code catches these (this is done slightly differently under Windows) and lets the Smalltalk execution thread reevaluate which Smalltalk processes if any may now be candidates for execution. In your case, when you enter the THAPI call, the Smalltalk process goes to sleep blocked on a simple Semaphore. A native thread is grabbed from the VM's native thread pool and asked to execute the appropriate external code. While that's happening, assuming the OS's scheduler gives some slices to the Smalltalk execution thread, it's free to execute any other runnable Smalltalk processes. When the thread doing the work finishes, the semaphore that Smalltalk process is waiting on is signaled, and the Smalltalk execution thread becomes aware of this (next message send or backwards bytecode jump) and acts accordingly. Short of it: sleep() should be fine in a THAPI thread. I've used nanosleep() before. If it's not, something's happening, but I wouldn't suspect sleep. I know that the one thing that can get really weird is if your external call does stuff that mucks with the signal handling, or emits its own signals. -- Travis Griggs Objologist "I think that we should be men first, and subjects afterward." - Henry David Thoreau |
|
|
Since I am working on my own debugger which will operate on Liberty BASIC
programs, there are a couple of things I am trying to do. First, and less important it would be great if I could somehow change the Ctrl+Y used to interrupt a running process to something more traditional for BASIC like Ctrl+Break. When looking into this I discovered that VisualWorks maps this to Ctrl+C. What's the best way to change this, or should I just see if my users will not object to Ctrl+Y? ;-) Okay, the more pressing issue is that when I try to put some sort of a switch in DebuggerService>>interruptActiveUserProcess so that I can choose to open my own debugger, then VisualWorks hangs when I press Ctrl+Y. First I tried a popup dialog to let the user choose BASIC or Smalltalk and wasn't too surprised when it hung as soon at the dialog appeared. I tried forking the dialog and using a semaphore. No luck. When I tried a simple Boolean global variable instead it was no better. Any ideas? -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com |
Re: [7.4]Highjacking the Ctrl+Y
|
|
At 09:06 AM 3/29/2006, Carl Gundel wrote:
>Since I am working on my own debugger which will operate on Liberty BASIC >programs, there are a couple of things I am trying to do. First, and less >important it would be great if I could somehow change the Ctrl+Y used to >interrupt a running process to something more traditional for BASIC like >Ctrl+Break. When looking into this I discovered that VisualWorks maps this >to Ctrl+C. What's the best way to change this, or should I just see if my >users will not object to Ctrl+Y? ;-) InputState class>>interruptKeyValue: also allProcessInterruptKeyValue: (the one that brings up the process manager). I did manage to make control-break work as a value for that somehow many years ago, but you did have to circumvent VW somehow to do it. I'm sure someone remembers how. >Okay, the more pressing issue is that when I try to put some sort of a >switch in DebuggerService>>interruptActiveUserProcess so that I can choose >to open my own debugger, then VisualWorks hangs when I press Ctrl+Y. First >I tried a popup dialog to let the user choose BASIC or Smalltalk and wasn't >too surprised when it hung as soon at the dialog appeared. I tried forking >the dialog and using a semaphore. No luck. When I tried a simple Boolean >global variable instead it was no better. Any ideas? Not sure what's happening there, but probably a more promising point to intercept would be to set Notifier>>current:. You can replace it with anything that implements #openException: and openContext:label:proceedable:. I think that's all the methods you need. So, for example, HeadlessImage implements those methods to do a stack dump when running headless rather than trying to open a graphical debugger. >-Carl Gundel, author of Liberty BASIC >http://www.libertybasic.com -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
Re: [7.4]Highjacking the Ctrl+Y
|
|
Carl:
You can load RuntimePackager and see how it puts its own notifier in as Alan points out: "Notifier>>current: myNotifier" but at least you have some code to study/mimic. BTW, will this be working by the time you present at NYC Smalltalk :) -Charles On Wed, 29 Mar 2006 10:10:28 -0500, Alan Knight <[hidden email]> wrote: > At 09:06 AM 3/29/2006, Carl Gundel wrote: >> Since I am working on my own debugger which will operate on Liberty >> BASIC >> programs, there are a couple of things I am trying to do. First, and >> less >> important it would be great if I could somehow change the Ctrl+Y used to >> interrupt a running process to something more traditional for BASIC like >> Ctrl+Break. When looking into this I discovered that VisualWorks maps >> this >> to Ctrl+C. What's the best way to change this, or should I just see if >> my >> users will not object to Ctrl+Y? ;-) > > InputState class>>interruptKeyValue: > also allProcessInterruptKeyValue: (the one that brings up the process > manager). > > I did manage to make control-break work as a value for that somehow many > years ago, but you did have to circumvent VW somehow to do it. I'm sure > someone remembers how. > >> Okay, the more pressing issue is that when I try to put some sort of a >> switch in DebuggerService>>interruptActiveUserProcess so that I can >> choose >> to open my own debugger, then VisualWorks hangs when I press Ctrl+Y. >> First >> I tried a popup dialog to let the user choose BASIC or Smalltalk and >> wasn't >> too surprised when it hung as soon at the dialog appeared. I tried >> forking >> the dialog and using a semaphore. No luck. When I tried a simple >> Boolean >> global variable instead it was no better. Any ideas? > > Not sure what's happening there, but probably a more promising point to > intercept would be to set Notifier>>current:. You can replace it with > anything that implements #openException: and > openContext:label:proceedable:. I think that's all the methods you need. > So, for example, HeadlessImage implements those methods to do a stack > dump when running headless rather than trying to open a graphical > debugger. > > >> -Carl Gundel, author of Liberty BASIC >> http://www.libertybasic.com > > -- > Alan Knight [|], Cincom Smalltalk Development > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk > > "The Static Typing Philosophy: Make it fast. Make it right. Make it > run." - Niall Ross -- Charles A. Monteiro |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |