Smalltalk › Instantiations

Calling a C (DLL) function that won't block the VM

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Louis LaBrunda

Calling a C (DLL) function that won't block the VM

Hi,

I have some C functions that I call within a DLL. They are build with the C part that one drops and tailors in the white space. This has worked well for years. Today, a call to a new version of the DLL with some new values to one of the DLL functions hung the VM/Image for almost 30 minutes until a program the DLL was using was forced to stop.

I'm wondering if there is a way to call the functions in a thread that won't block the VM? I don't mind (in fact I prefer) if the calling fork is blocked but not all other forks.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/tykFySMWIHIJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Marten Feldtmann-2

Re: Calling a C (DLL) function that won't block the VM

Your friends are all methods called

PlatformFunctions>>asyncCall*

in VASmalltalk. I've made 8 screencasts about calling external C-function and the specific one to that call can be downloaded from http://smalltalkinspect.podspot.de/post/msc006-c-api-part-05-en/.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/loHDRROyF-8J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

bonndias

Re: Calling a C (DLL) function that won't block the VM

Our friends are all methods called

PlatformFunctions>>coroutineCall*

We switched from asyncCall* to coroutineCall* a few years ago for reasons I can't remember, but it solved a problem. Perhaps someone else here can point out the differences and advantages of each approach.

Am Freitag, 14. September 2012 07:11:29 UTC+2 schrieb Marten Feldtmann:

Your friends are all methods called

PlatformFunctions>>asyncCall*

in VASmalltalk. I've made 8 screencasts about calling external C-function and the specific one to that call can be downloaded from http://smalltalkinspect.podspot.de/post/msc006-c-api-part-05-en/.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/lm42NFMkhWUJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Marten Feldtmann-2

Re: Calling a C (DLL) function that won't block the VM

The staticFuture* handles a very special use-case: it allows calls to external-libraries from the SAME native thread, which is a prerequisite in several c-libraries.

Another use case is, that - by using futures - the programming model in Smalltalk may be simpler to handle. Otherwise you must execute the async call in a separate Smalltalk thread ... tedious.

You must not do any async calls from the GUI thread, because the async call blocks the calling Smalltalk thread - but it IS possible with a staticFutureCall*.

The coroutineCall MAY lead to a synchronous call OR a static future call. It is therefore located - in the programming layer - above all possible external calling possibilities. It seemed to be an interface on platforms, where thread support was not available - which is not the case any more on all supported platforms. The coroutine call therefore has the same thread semantic as synchronous call and static future call. By giving a key value as a parameter you can get access to the specific future call you want to use.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/lHwG5bH7ANUJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Louis LaBrunda

Re: Calling a C (DLL) function that won't block the VM

Thanks Marten & Bonndias,

Thanks for the replies.

The code I'm talking about is very, very old and was, as I said, built in the white space with the C parts. I would like to keep all those C parts if I can as it would be a lot of work to re-do all the function calls any other way. The settings for these white space items seem to have a "Long operation" check box option. Non of these are currently checked. From what I can tell, checking this option will result in the operation running in a separate thread. Does anyone know if this is indeed the case? Will the code that calls these functions with the long operations set still wait until the operation is finished? If the answer to both these questions is true, then it looks like what I want.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/zb8yMH5DtYIJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Marten Feldtmann-2

Re: Calling a C (DLL) function that won't block the VM

Yes, it will wait - actually it will ends up in

PlatformFnction>>coroutineCallOnThreadKey: aThreadKey withArguments: parmArray

and the key is the Smalltalk process calling this. The waiting is forced by the last statement (sending value to the future).

Am Freitag, 14. September 2012 22:33:55 UTC+2 schrieb Louis LaBrunda:

in a separate thread. Does anyone know if this is indeed the case? Will the code that calls these functions with the long operations set still wait until the operation is finished?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/Wq2aXBWoufEJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Marten Feldtmann-2

Re: Calling a C (DLL) function that won't block the VM

Ok, my last answer gave the details, what happens under the hook and what is called.

When answering that question I began to ask myself: if the Smalltalk execution of that part is executed in the Smalltalk GUI thread - does it still block the GUI on a long term call ?

I would expect it so - actually the "anACOFuture value" statement just leads to a "aSemaphore wait" statement.

Execute that statement in a workspace and your system is locked.

But try it and tell here what happens.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/mZjmyDaylD8J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

John O'Keefe-3

Re: Calling a C (DLL) function that won't block the VM

Historically, there are 2 kinds of Semaphore -- one that blocks the UI process and one that doesn't (by spinning up a new UI process and blocking on the old UI process). You can get the non-blocking behavior by 1) using an AbtSemaphore together with a #wait or 2) Using a Semaphore together with an #abtWait. I think (don't have an image open right now) that CoroutineCall uses AbtSemaphore.

John

On Saturday, September 15, 2012 1:54:50 AM UTC-4, Marten Feldtmann wrote:

Ok, my last answer gave the details, what happens under the hook and what is called.

When answering that question I began to ask myself: if the Smalltalk execution of that part is executed in the Smalltalk GUI thread - does it still block the GUI on a long term call ?

I would expect it so - actually the "anACOFuture value" statement just leads to a "aSemaphore wait" statement.

Execute that statement in a workspace and your system is locked.

But try it and tell here what happens.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/tfwoJM9_ndoJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Louis LaBrunda

Re: Calling a C (DLL) function that won't block the VM

Hi Marten and John,

Thanks for the info. In this case the program is running as an NT service, so, there is no GUI and I guess no UI process although I do see references to a UI for such headless programs. Anyway, I want the process making the call to wait but I would like other processes to continue to run. If that's the way things work, I'm good.

Lou

On Sunday, September 16, 2012 12:19:06 PM UTC-4, John O'Keefe wrote:

Historically, there are 2 kinds of Semaphore -- one that blocks the UI process and one that doesn't (by spinning up a new UI process and blocking on the old UI process). You can get the non-blocking behavior by 1) using an AbtSemaphore together with a #wait or 2) Using a Semaphore together with an #abtWait. I think (don't have an image open right now) that CoroutineCall uses AbtSemaphore.

John

On Saturday, September 15, 2012 1:54:50 AM UTC-4, Marten Feldtmann wrote:
Ok, my last answer gave the details, what happens under the hook and what is called.

When answering that question I began to ask myself: if the Smalltalk execution of that part is executed in the Smalltalk GUI thread - does it still block the GUI on a long term call ?

I would expect it so - actually the "anACOFuture value" statement just leads to a "aSemaphore wait" statement.

Execute that statement in a workspace and your system is locked.

But try it and tell here what happens.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/rC40s_oSQ30J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.