There is a serious problem in the design of virtual print. After forking virtual print transaction threads and comparing
threads, the socket path which is used by inter-thread communication, and reqFlg which indicate the work status of comparing
threads, are both set by virtual print threads. The value of reqFlg is set to "enable" at first.
As a rule, a virtual print thread need more time to work than the work time of a comparing thread. However, under some
extreme, for example, a virtual print thread finished its collecting job so quickly, at one time, the corresponding comparing
thread met some trouble and can not be in the "enable" status; the starting message from the virtual print thread can not be
received, even though received the message, it also can not get in work well.
So, this time system will be in a kind of chaose.
The obvious problem, our customer still inssisted in their design. Why? Why adopt a safer way to avoid the bug?
threads, the socket path which is used by inter-thread communication, and reqFlg which indicate the work status of comparing
threads, are both set by virtual print threads. The value of reqFlg is set to "enable" at first.
As a rule, a virtual print thread need more time to work than the work time of a comparing thread. However, under some
extreme, for example, a virtual print thread finished its collecting job so quickly, at one time, the corresponding comparing
thread met some trouble and can not be in the "enable" status; the starting message from the virtual print thread can not be
received, even though received the message, it also can not get in work well.
So, this time system will be in a kind of chaose.
The obvious problem, our customer still inssisted in their design. Why? Why adopt a safer way to avoid the bug?
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
