Re: How to implement a driver's read and write operations with synchronization properly
On Tue, Jul 29, 2014 at 7:47 PM, Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:
I've tried this out myself, and it seems to be an issue with bash:
As you can see, I observed the same pattern of 1008 and 993 bytes.
I think you're right. The split is done by the user program, separated from kernel land. So I guess it's reasonable to use the 1st approach, which is to always release the lock at the end of the operation. But still, user programs like bash could have a race problem by spliting the input, I hope that they can somehow take care of this problem themselves. Thanks guys. -- Le Quoc Anh
On Tue, 29 Jul 2014 20:59:08 +0700, Anh Le said:
still, user programs like bash could have a race problem by spliting the input, I hope that they can somehow take care of this problem themselves.
stdio is *not* always your friend. fopen/fprintf is prone to splitting on bugger boundaries without your knowing about it, but most language bindings (including the Perl you tested with) allow you to use open/write and do the buffer management yourself
On Tue, Jul 29, 2014 at 10:24:41AM -0400, Valdis.Kletnieks@vt.edu wrote:
On Tue, 29 Jul 2014 20:59:08 +0700, Anh Le said:
still, user programs like bash could have a race problem by spliting the input, I hope that they can somehow take care of this problem themselves.
stdio is *not* always your friend. fopen/fprintf is prone to splitting on bugger boundaries without your knowing about it, but most language bindings (including the Perl you tested with) allow you to use open/write and do the buffer management yourself
Actually, the Perl's IO layer did pretty little to the result, because Anh used command line substitution: echo $(perl -e "print 'a'x2000") > /dev/sample Jonathan
participants (3)
-
Anh Le -
Jonathan Neuschäfer -
Valdis.Kletnieks＠vt.edu