[Gtk-sharp-list] Creating critical section for unhandled exception handler

Christopher David Howie me at chrishowie.com
Thu May 20 23:24:57 EDT 2010

On 5/20/2010 9:16 PM, Styne wrote:
> I'm confident that I have proven:
> 1) A thread that enters the critical section will block until the dialog is
> closed (Dialog.Run() blocks, plus the counter doesn't decrement until the
> dialog is closed)
> 2) There are multiple threads in the same critical section at the same time
> (multiple dialogs, plus counter > 1)
> 3) It is the same thread that is re-entering the critical section without
> ever leaving it (same ManagedThreadId which is guaranteed to be unique for
> each thread)
> Is this a bug or am I doing something wrong?

This is probably the main thread, if you are responding to a Gtk# event,
since these events are dispatched on the main thread.  When you show the
dialog, the Run() call will indeed block, but the main loop will be
re-entered on the same thread so that events in the dialog can be processed.

So if some event occurs multiple times, the same event that triggers the
code you are running to show the dialog, then that code will be
re-entered recursively.

Chris Howie

If you correspond with me on a regular basis, please read this document:

PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5


This document should be read only by those persons to whom it is
addressed.  If you have received this message it was obviously addressed
to you and therefore you can read it.

Additionally, by sending an email to ANY of my addresses you are
agreeing that I am, by definition, "the intended recipient," and that I
may do whatever I wish with the contents of any message you send me,
unless a pre-existing agreement prohibits me from so doing.

This overrides any disclaimer or statement of confidentiality that may
be included on your message.

More information about the Gtk-sharp-list mailing list