-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
sys: newlib: make _read_r thread safe #3136
sys: newlib: make _read_r thread safe #3136
Conversation
Good catch! |
be4fc65
to
5549d04
Compare
-rebased |
ACK for the change |
Did you test this on the IoT-Lab? |
Yes, working fine. |
no wait, I was testing default, and that uses uart0 ;) sec... |
Checked iot-lab. |
count = count < rx_buf.avail ? count : rx_buf.avail; | ||
|
||
return ringbuffer_get(&rx_buf, (char*)buffer, count); | ||
res = ringbuffer_get(&rx_buf, (char*)buffer, count); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for a late comment: I noticed that ringbuffer_get returns an unsigned int, do we need to cast that here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, before we just returned ringbuffer_get directly. And the compiler doesn't complain. And no RIOT device in the near future will have a ring buffer with 2^31 bytes, so not casting should be fine. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, just nitpicking. We can merge this as-is in my opinion
ACK |
sys: newlib: make _read_r thread safe
previously, there was a potential race condition because both ISR and the thread could access the ringbuffer simultaneously. This PR wraps the ringbuffer access from the thread into disable/restreIRQ calls.
(depends on #3111)