[Mono-dev] Thread Abort() sometimes fails in mono

Felipe Almeida Lessa felipe.lessa at gmail.com
Tue Apr 4 14:08:44 EDT 2006


Em Ter, 2006-04-04 às 11:50 -0600, Wade Maxfield escreveu:
>    I agree that a sleep() is a good thing while waiting for thread to
> start running.  However, I thought one of the points of "managed" code
> was to allow this sort of thing, not necessarily paying attention to
> cpu loading issues, as well as memory issues?  That is why I swallowed
> MS's tutorial hook line and sinker.  

No. Really. Managed code help you in loads of usual problems while
programming and deploying, but paying attention to CPU and memory issues
is something you need in *every* language currently available. If you
don't mind those you may end up with a bloated and slow program.

>   In any case, regardless of the efficacy of the program I've written,
> the point that mono developers must ponder is that other coders
> following my footsteps will code exactly the same way, the way that
> Microsoft Tutorial states it should.  When it fails to abort under
> mono, but always aborts under .NET, they will claim it is a bug in
> Mono.

I don't know why the Mono implementation does not work as the MS one,
but even in MS .NET I would use the pattern described in my last e-mail,
so I wouldn't even notice the difference. Is there any Mono guru reading
this e-mail?

>   It does appear I overlooked a join() call, which forces the first
> thread to deadlock until the abort happens.  However, I never had the
> problem of a failing abort in .NET.  In this case, I could care less
> if the thread aborted a few hundred milliseconds to one second later
> than the main thread.
> 
>   As I indicated earlier, I set a variable which caused my routine to
> bail, causing the thread to naturally abort (similar to your proposal,
> but more crude).  This method will work in all versions, .NET and
> Mono.

IIRC, you can also #ifdef for the appropriate action. But that would
turn .NET's binaries incompatible with Mono.

Cheers,

-- 
Felipe.




More information about the Mono-devel-list mailing list