only unsafe as in not 'type'safe, in that often data or function pointers
were usualy converted to longword in the event parameters etc. and
"hide" as in hidden under wrappers lol
Okay.
Well from what I have read of BeginInvoke it does use a another thread
from the pool to call invoke, not just posting the message on the thread
message queue, if it did this that would be fine.
It seems crazy it doesnt do that, maybe I read something that was wrong
or grossly out of context.
Im sure it was invoked through a pool thread though..
Likely you were reading something about using BeginInvoke on a delegate
directly. If I recall correctly, that does execute the delegate on a
thread pool thread.
But obviously, since when used with a form the whole point is to have the
delegate run on the form's thread, when you use BeginInvoke on a form, the
delegate must execute on the form's thread, not a thread pool thread. It
wouldn't make sense any other way.
I dont realy have the option of waiting for certain amount of time to go
by in the com thread, or waiting for a number of data items.
I never said anything about waiting. Simply keeping track of. At
appropriate points in your i/o code, you simply check the current time, or
check the number of bytes transferred since the last update, and if enough
time has gone by or enough bytes has been transferred, you post your UI
update.
the com task is high priority so it is possible it would queue up many
requests. and it is also possible it will suddenly stop.
That's the whole point. It wouldn't queue up many requests, because you
would deliberately fix the code to prevent that. By posting UI updates
only at particular intervals, you would ensure that not too many updates
got queued up. Not that I believe that there should be any problem
posting updates with every i/o operation anyway, but if you believe that's
a problem there is a simple solution.
[...]
that might be a good place to put the code, but I think the form has
disapeared by then,
the serial port is part of the form as it was added with the designer,
maybe this will have to be moved, unless there is somewhere the form
disapears from screen but not deleted.
I see no reason for the serial port to be part of the form. That's a
convenience, and the moment it gets in your way, you should put it
somewhere else. I don't personally see any reason it should be a problem
for the form to remain until the application has really shut down, but if
that's a design requirement for you, it is easy enough to simply
instantiate the serial port component elsewhere.
You could, of course, also just hide the form initially while you wait for
the cleanup to finish.
And of course, the fact that you include the serial port on the form in
the designer doesn't mean that you can't keep a reference to it somewhere
else. Unless the form designer adds code that explicitly disposes the
serial port component (I didn't check, but I don't see why it would), the
form can be closed just fine without affecting the serial port.
There are a number of ways to deal with the application exit scenario, all
of which seem just fine to me. I doubt that this is an area of your
program that deserves a lot of hand-wringing.
PS:
hmm actually ive just removed the abort and set an exit flag and dont
bother to wait anymore,
this seems to solve the deadlock problem, just need to try make sure it
exits cleanly with all the possible combinations of switching on and off
the remote device and stopping starting the pc software etc.
Well, as I mentioned, your form thread can exit without affecting the
other non-background threads in the application. They will continue to
run until they exit, allowing them to perform whatever cleanup you need
them to do.
I was never entirely sure what the error message was complaining about
exactly enyway.
Well, "complaining" isn't a very precise term. You would probably get
good advice on the meaning of the error, if you actually posted the exact
text of the error.
I had a background worker thread before wich might have been the cuase of
the problem.
Perhaps. Background threads don't prevent the process from terminating,
and get aborted automatically. If you have something running on a
background thread that shouldn't be aborted, that could definitely cause
an issue.
Well yes its included but it seems to be causing a lot of confusion to
people judging by the amount of posts ive read asking about it, and the
numerous different explanations.
Multi-threaded code is complicated. Fact is, given how easy it is to get
into a multi-threaded situation in .NET, it may be that more people are
writing multi-threaded code than ought to be. But obviously one can do
multi-threading just fine in .NET.
Ive written real time operating executives back in the days of 80286, and
admitdetly ive only been at this a week but I find it frustratingly
difficult to find what I need when there is so much emphasis on being
able to create a simple program in 60 seconds lol.
There's no such thing as a simple multi-threaded program. Yes, .NET makes
many things much easier. And a person experienced in .NET programming
definitely CAN create a simple program in "60 seconds" (give or take a
minute). But what you are doing is not exactly simple, and you can't
expect to be able to take full advantage of the rapid-deployment aspects
of .NET before you have taken the time to learn how .NET works.
IMHO, you should adjust your expectations to be more in line with the
level of experience you have with .NET. I'm not saying .NET is
problem-free, but it seems to me that you are spending too much time
assuming that .NET can't do what you want or that it has fundamental
problems, rather than exploring the possibility that you just have some
things to learn before you can efficiently implement solutions in .NET.
I agree entiriely that its easier to do this sort of thing with much more
safety, (as in type safe)
underneath delegate is a function pointer hidden under heavy wrappers,
and it may produce less code wich maybe be easier to keep track of,
but for it to be easier overall im not convinced as yet.
It seems to me that in the context of .NET, delegates are exactly the
right solution to the same problem function pointers address in C/C++. I
have not seen delegates as being any more difficult to use than a function
pointer, and they are type safe. What sort of "convincing" is it that you
feel hasn't happened yet? It's not like you have to go to any extra work
to use delegates; they are basically the same as function pointers and
frankly, I find the syntax more sensible than that used for function
pointers in C/C++.
It would be easier if they removed the need to write any of the
synchronizing code yourself at least for the main culprits such as the UI
controls. although deadlock type issues are notoriously difficult to
ensure they dont happen, but then the new methods are not particularly
transparent and hence not easy to see such conflicts.
Deadlocks are always an issue, and I don't see how a language can prevent
them. Perhaps one day, if someone figures out how to make a computer
program provably correct, we'll get a compiler that does that. Until
then, we're left with the problem that computer programs can be
arbitrarily complex and preventing deadlocks isn't possible.
As far as the cross-thread form execution issue goes, I agree that's a
pain in the neck. It's unfortunate that rather than simply smoothing over
that wrinkle, .NET simply propogates the pre-existing Win32 issue. But
make no mistake...the issue is a Win32 issue, not one of .NET.
Pete