C# - SmtpMail.send() does _not_ cause button click to block . . .

Author

SmtpMail.send() does _not_ cause button click to block . . .

glaserp@sustainsoft.com

2005-09-06, 7:56 am

Hi,

I asked this question on the windowsforms group five days ago and
didn't get any response, so I'm hoping someone here can help.

I am using a simple form to test a library I am developing. The library
reads data from a database, puts together a report, and then sends the
report to a number of email recipients. I am initiating this process by
clicking a button on the form.

The smtp server I'm working with is a bit sluggish, so the
SmtpMail.Send() is taking about 5-10 seconds to return (don't ask; this
is out of my control). Stepping through the code in the debugger,
something a bit odd happens: it appears as if Send()returns
immediately, and the form pops back up, without any of the code
following Send() being executed. I wait the amount of time I know that
Send() really takes, and then the debugger pops back into the code at
the line just following Send(). I do not see this behavior if I drive
the library from a console app: here, the blocking behavior of Send()
causes the debugger to sit and wait until Send() returns, as one would
expect.

What's going on here? It almost seems as if the Application is deciding
that the execution of Send() is taking too long and somehow putting it
into the background. I don't understand how that could be happening
given that I never created a new thread for it to execute. Moreover, it
seems to me that this behavior could cause major problems upon
re-entry. For example: the GUI becomes active, and so I click the test
button again, and it ends up re-running code that is not intended to be
thread safe; what if I'm in the middle of re-running that code when
Send() does return?

In production, this library will be driven from from a windows service
application. Might the difference between exercising this code through
a GUI, versus through a command-line app, be the presence a message
loop? If so, then this problem remains relevant in the service
application, and I need to figure out what to do.

Can this behavior be controlled, or do I have to run SmtpMail.Send() in
its own thread in order to head this problem off?

Thanks.

--Phil

Jan Bannister

2005-09-07, 6:59 pm

Hi Phil,

I think you answered your own question at the end. If i were you I
would run any lengthy blocking calls in their own thread. That way you
know that your the one in control of the thread.

With regard to the unusual problem you experienced with the debugger,
I've noticed it too. I a similar situation, I wasn't able to get an
answer about it but I also assumed that it was the IDE backgrounding
the blocked thread to keep the debugger responsive. This seemed to be
confirmed by looking at the Threads window.

Not much help, just my 2 pence...
Jan

Ciaran

2006-01-10, 4:09 am

This is just a feature of debugging in visual studio, if a call takes a long
time, it shows you your app for while thinking it has finished debugging
your code. Then when the control comes back to your code it activates the
debugger like a break point.

It will be fine when not in debug.

Ciaran O'Donnell
There are 10 types of people in this world. Those that understand binary and
those that don't

<glaserp@sustainsoft.com> wrote in message
news:1126007927.881077.245710@g14g2000cwa.googlegroups.com...
> Hi,
>
>
> I asked this question on the windowsforms group five days ago and
> didn't get any response, so I'm hoping someone here can help.
>
> I am using a simple form to test a library I am developing. The library
> reads data from a database, puts together a report, and then sends the
> report to a number of email recipients. I am initiating this process by
> clicking a button on the form.
>
>
> The smtp server I'm working with is a bit sluggish, so the
> SmtpMail.Send() is taking about 5-10 seconds to return (don't ask; this
> is out of my control). Stepping through the code in the debugger,
> something a bit odd happens: it appears as if Send()returns
> immediately, and the form pops back up, without any of the code
> following Send() being executed. I wait the amount of time I know that
> Send() really takes, and then the debugger pops back into the code at
> the line just following Send(). I do not see this behavior if I drive
> the library from a console app: here, the blocking behavior of Send()
> causes the debugger to sit and wait until Send() returns, as one would
> expect.
>
>
> What's going on here? It almost seems as if the Application is deciding
> that the execution of Send() is taking too long and somehow putting it
> into the background. I don't understand how that could be happening
> given that I never created a new thread for it to execute. Moreover, it
> seems to me that this behavior could cause major problems upon
> re-entry. For example: the GUI becomes active, and so I click the test
> button again, and it ends up re-running code that is not intended to be
> thread safe; what if I'm in the middle of re-running that code when
> Send() does return?
>
>
> In production, this library will be driven from from a windows service
> application. Might the difference between exercising this code through
> a GUI, versus through a command-line app, be the presence a message
> loop? If so, then this problem remains relevant in the service
> application, and I need to figure out what to do.
>
>
> Can this behavior be controlled, or do I have to run SmtpMail.Send() in
> its own thread in order to head this problem off?
>
>
> Thanks.
>
>
> --Phil
>

SenorPr0n

2006-01-10, 4:09 am

I would always be careful about threading when dealing with sockets.
While Ciaran is right that you shouldn't have a problem while running
it, if certain socket functions are threaded and they don't complete
before the code progresses to the next lines of code, you may get some
NullReferenceExceptions among other things. When dealing with sockets
always make sure you are writing code that is thread-safe.

Bruce Wood

2006-01-10, 4:09 am

I've run into this in a few cases in my code: situations in which if
the user double-clicks quickly enough on a button, it clicks the button
twice.

I changed my code (in the offending spots) to disable all controls on
the screen then launch into doing its work, then re-enable all of the
controls when it's done. No, it's not pretty, and no, it didn't help me
completely understand what was going on, but it works.

Sponsored Links