Hi Felipe,
the code looks fine to me, we have not run in that concurrency issue
but i think that your approach is very good and it could happen
My only concern is your patch coding style:
- we use spaces instead of tabs
- each tabs is 4 spaces
- any 'if/else' must contain a {}
- local functions are prefixed with _, e.g: _next_buffer()
Please also add a description on top of _next_buffer() function...
You can indent/format your code with:
indent -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 -nut FILE
that's all for now, once you fix the coding style issue i am able to
apply your patch,
cheers!
On Sat, Mar 17, 2012 at 4:58 PM, Felipe Astroza <[email protected]> wrote:
>
> Time strings are build in clock worker thread every one second. The issue
> doing that is while the string is being build (in half the work), another
> worker thread could use this unfinished string. Example:
> We have:
> [16/Mar/2012 23:59:59 -0300]
> An unfinished string could be like:
> [17/Mar/2012 23:59:59 -0300]
> And that is bad!.
> My approach to the solution is to have two buffers, like double screen
> buffers to avoid glitches, but applied to time strings. So, there is no
> half-way string.
>
> Signed-off-by: Felipe Astroza <[email protected]>
> ---
> src/mk_clock.c | 67 ++++++++++++++++++++++++++++++++++++-------------------
> 1 files changed, 44 insertions(+), 23 deletions(-)
>
>
> _______________________________________________
> Monkey mailing list
> [email protected]
> http://lists.monkey-project.com/listinfo/monkey
>
--
Eduardo Silva
http://edsiper.linuxchile.cl
http://www.monkey-project.com
_______________________________________________
Monkey mailing list
[email protected]
http://lists.monkey-project.com/listinfo/monkey
