Re: Signal-Unsafe Problem
- From: "Jan Tomka" <Jan.Tomka@xxxxxxxxx>
- Date: 26 May 2006 05:56:48 -0700
LaBird wrote:
Thanks a lot, I will try your recommended solution.
About the sig_atomic_t flag issue, the problems for my program are that
(1) My program is also busy running other code. So I cannot afford a
loop for busy checking the flag, nor even polling, and
(2) Messages arrive very frequently. A lot of messages may accumulate
(receive buffer inside socket may use up) before the first one get served,
if I delay handling the arrived messages.
Is there any way to solve such problem?
Well, you only have 100 % of CPU time. You can get no further. Once you
start receiving more messages than you can process at that time,
they'll simply have to wait in a queue until you're done with the
previous ones. What you must do, is to try utilizing the CPU the best
possible way.
There's no need to run a busy loop for the flag alone. Infinite
select/poll would do much better in such case, but that is not the
approach you want.
I guess your program already has some sort of main loop, you only need
to put a check somewhere into it. Once the flag is risen, you know I/O
functions won't block.
You can either process incoming data right away, or copy it to the
message buffer. Then you can go on with your main loop and do some
processing on data gathered so far.
Rule of thumb is to keep your functions (relatively) short, _never_
blocking, not taking too long to finish. Your main loop than can be
repeated fast enough to both handle incoming data and do the processing
in a fair manner.
If the messages received are too complex to handle "quickly", or the
nature of processing does not allow you to get it done "quickly", you
should prepare your functions to process data sequentially, in more
passes, spanning several main loop iterations. In such case you need to
keep track of what is called context: where have you suspended
processing the last time, what were you doing etc.
But all this is only a single approach to make things work. As I
mentioned, others might apply depending on real nature of the problem.
.
- References:
- Re: Signal-Unsafe Problem
- From: Jan Tomka
- Re: Signal-Unsafe Problem
- From: LaBird
- Re: Signal-Unsafe Problem
- Prev by Date: Re: objdump'ed code correspond to C code
- Next by Date: Re: UTF8 file handling API's
- Previous by thread: Re: Signal-Unsafe Problem
- Next by thread: Re: Signal-Unsafe Problem
- Index(es):
Relevant Pages
|
Loading