Blocking on command_execute?

[Ron]

You are right!, upgrading Jon's status :smile:

[Ron]

I've just double checked the code and girder does not create a thread for this. So Girder should block as long as you don't return from the execute_command. I can make a little dummy plugin to see if it actually blocks Girder, but i expect so.

[Ron]

There are different kind of messageboxes,.. and some of them don't block!! Please verify you got the right one.

[Ron]

I tried a dummy plugin and I found the same thing, after long searching in the Girder code where the new thread is started I found nothing. Not suprising as I didn't design it that way. My only conclusion is that Delphi is doing this in the UI thread. Of course that isn't what i'd like to happen. I'll add a mutex in the next release to prevent this from happening.

-Ron

[Ron]

Okay I just tried the mutex, and it doesn't block, indicating that it is the same thread requesting the mutex.... I have no clue why this is happening. If I try to excute a command twice by pressing F5, the UI blocks the second event, but if i go into the menu and press the test command it does work... I'm lost. How big a problem is this for you ? Cause it looks like a strange quirk of Delphi. The core will be rewritten in C/C++ towards the end of the year.

[Ron]

Maybe keep a call list with a maximum length of 10 or so... if the 11th call comes just throw it out.

[Mark F]

What do you mean by "block"? Or better yet, how do you block the thread? What what mechanism/call do you use?

The serial plugin writes data to the com device (with an infinite timeout) which means the thread has an opportunity to block for a LONG time. :smile: That plugin also has intra-character and intra-command delays that can block (using the sleep function) and I've not seen a re-entrancy situation. Maybe I am lucky?

[Mark F]

Ron - You need to change Jon's title. :smile:

[jon_rhees]

Ron,

I've noticed something unexpected when I block in command_execute. I had expected Girder to become blocked as well, but I found that it instead appears to re-entrantly call the command_execute function even when there are instances of it blocked.

Does Girder create a new thread for each of these? Does Girder allow a command_execute function to block but only for a limited time?

I need to understand this better so that I can handle blocking better (since IR Transmission can be slow).

Thanks!

-Jon

[jon_rhees]

Guys,

Here's what I saw happen...

I was checking for a stalemate situation within my plugin, and so I had added some 'MessageBox()' commands inside of command_execute. I was calling my action every few seconds using the AlarmTimer Plugin. I came back to the computer to find about two dozen messageboxes piled on the screen, and another one showing up about every 10 seconds. As far as I know, these messageboxes block a thread. I brought up the Girder screen (took a while), and sure enough, no 'response' messages were showing up in the status bar either.

Perhaps this is an issue with using AlarmTimer -- but I would imagine that it is generating its events using the SendMessage mechanism???

So if you want to try this yourself, simply create a command_execute that throws up a messagebox() and returns. Then set up a .gir file to call is from the timer_end part of AlarmTimer.

-Jon

[jon_rhees]

Ron,

I am calling the Win32 MessageBox:

Reads:

MessageBox(NULL /*hWnd*/, "Text", "Caption", MB_OK);

This has always blocked for me (sometimes I use them to pause code, etc. for debugging). Is there a nonblocking version of this very call?

Thanks!

-Jon

P.S. I also tried putting two MessageBox calls in a row, and they displayed one at a time (had to click OK on the first before the second one popped up).

[jon_rhees]

In the past I was having unexplained problems with Mark's serial plugin 'locking up' when transmitting lots of periodic data (caused by either AlarmTimer or DVDSpy events). My guess is that the same thing might have been happening there. I suspect that funny things happen when you make two calls to WriteFile with the same COM handle that are on top of each other in time...

-Jon

[jon_rhees]

I think the big issue for me is deciding what to do when I see a reentrant call to command_execute. I can detect this simply enough -- I can use a simple boolean flag I set at entry (after the check), and reset at exit. I can then detect a second call to command_execute before the first has returned. BUT, I'm not sure what I should do in this case.

It sounds like if I block at that level (waiting for the first to finish), we may pile up a whole bunch of calls. On the other hand, if I return without doing anything I just threw someone's action away.

Thoughts???

-Jon