I tend to avoid multithreading when I can, just because it complicates
everything, but in this case I don't see how you can get around it.
The problem, as I understand it, is that you have no idea how long it's
going to take the user to make a decision about what to do with the
data, and so it's not really an option to wait for a response before
you react to other events coming in from the RS port.
Therefore, you have little choice but to change your architecture.
Basically, you should be stacking up data coming in from the RS port in
a queue of some kind while the user is making up his or her mind as to
what to do. Whenever you get an event from the RS port you should
immediately grab the data from the buffer, stick it in some object, and
then queue that object for processing.
When the first piece of data arrives, the program must ask the user
what to do with it, but you can't ask on the same thread on which
you're reading from the RS port, because you can't afford to have the
question to the user blocking you while more data is coming in.
This means (to me) that somehow you have to be reading the RS port from
a background thread, while you ask the user what to do on the main UI
thread.
When the user finally responds, you then process all of the data in the
queue and then wait for more to be queued. I assume that this would be
a yet a third thread, that would simply read from the queue and deal
with the data, then when the queue is empty go to sleep and wait to be
woken up when there is more data in the queue.
At the very least you need something, like a queue, between the RS port
read and the processing to be done, so that data can build up while the
user is deciding what to do and nothing will be lost.