Razelo 기술노트

지난번 포스팅에서 코루틴 빌더 함수와 Job객체에 대해 알아보았다.  이번 포스팅에서는 async와 Deferred에 대해서 알아보자.  이전에 배운 launch 코루틴 빌더 함수는 코루틴으로부터 결과값을 받을 수 없었다. 다만 Job객체를 받을 뿐이었다.  그런데 코루틴으로부터 작업에 대한 결과값을 받을 필요가 있을 수 있다. 이때 사용하는데 async와 Deferred응답 객체이다. async(Dispatchers.IO) { ... }와 같이 사용할 경우 Deferred를 리턴받고, 해당 Deferred타입의 변수에 대해 await()메서드를 사용하면 결과를 받을 수 있다. await()을 사용하는 이유는, 코루틴이 언제 완료될지는 모르기 때문에 Deferred가 미래의 값이라는 의미..

지난번 포스트에 이어 코틀린 코루틴에 대한 개념 정리를 이어가고자 한다. 코루틴에는 CoroutineStart.LAZY를 사용한 코루틴 지연이라는 개념이 있다. 왜 코루틴을 지연해야할까? 코루틴을 CoroutineDispatcher의 큐에 제출했다고해서, 곧장 코루틴을 특정 스레드에 할당해서 바로 실행해선 안될때 필요하기 때문이다. 그저 실행해야할 코루틴을 미리 만들어두고 나중에 실행시키는 것이다. 이 경우 launch의 start인자로 CoroutineStart.LAZY를 주어 제출하면 된다. 그리고 이후에 실행시킬 필가 있을때 start시키면 된다. 지연하고 나서 이후 시작할 수 있는 방법은 launch 코루틴 빌더함수를 통해 받은 Job객체를 사용하면 된다. Job객체는 코루틴을 실행시킬 수 있는 ..

최근 코틀린을 다룰 일이 있었다. 코드는 그냥 작성하면 되는데, 코루틴에 대한 개념이 좀 부족했다고 생각했다. 애매하게 알고 있는 상태에서 코루틴의 기능을 쓰는게 썩 기분이 좋진 않았다. 뭔가 찝찝했다. 그래서 이번 기회에 코루틴에 대해 시간을 갖고 천천히 알아보고자 한다. 코루틴은 기본적으로 경량 스레드라고 불린다. 왜 경량 스레드냐면, 스레드에 붙였다 뗄 수 있기 때문이다. 왜 코루틴이 필요하냐를 정리하자면, 멀티스레드 프로그래밍에서의 일부 한계점을 극복하고자함이다. 우선 싱글 스레드부터 살펴보자. 스레드가 하나이므로 단 하나의 작업만 할 수 있다. 모든 일은 순차적으로 진행된다. cpu바운드던, 네트워크 IO 작업이던 모든지 하나라서 그다지 효율적이지 않다. 그래서 등장한게 멀티스레드 프로그래밍이다..

러스트 이중 연결리스트에 대한 코드다 use std::cell::RefCell; use std::rc::{Rc, Weak}; pub struct Node { data: isize, next: Option, prev: Option, } pub struct List { head: Option, foot: Option, } impl List { pub fn new() -> Self { Self { head: None, foot: None, } } fn new_node(v: isize) -> Rc { Rc::new(RefCell::new(Node { data: v, next: None, prev: None, })) } pub fn push(&mut self, v: isize) { let n = List::new..

좋은 노래가 있어서 공유해둔다... 서동현 - 직항 https://www.youtube.com/watch?v=FVPuS2A73FM

최근 흥미로운 내용을 접했다. C language의 연산자 우선순위에 설계상 결함이 있다는 이야기다. 전설의 C에 언어 설계 결함이 있을 수 있나? 라는 생각이 들었다. (지금도 결함 정도로 생각되진 않지만) 내용은 이렇다. & | 연산자와 == 연산자 간의 연산자 우선 순위로 인해 실수할 여지가 크다는 내용이다. & | 보다 ==의 연산자 우선순위가 더 높기 때문에 문제가 될 수 있다고 한다. 아래 코드가 있다고 보자. if (a & b == c) { // ... } 위 코드는 a&b의 결과가 c와 동등한지 확인하는 코드가 아니다. 오히려 b==c가 먼저 평가되고 그 결과와 a와 bit and를 한다. (당연히도) 해당 의견을 접하고 먼저 든 생각은 이렇다. 이게 왜 설계상 오류일까? 연산자 우선순위가..

https://www.youtube.com/watch?v=O-2viBhLTqI&t=1285s

https://m.blog.naver.com/dorergiverny/223032334186

DynamoDB의 근간은 2007년 AWS에서 내놓은 Dynamo 논문에 기반을 둔다. 해당 논문을 읽어보고 간략하게 내용을 정리해보고자 한다. 주의 개인 학습을 위해 러프하게 읽어본 내용이라서 중간에 잘못 해석한 내용이 있을 수 있습니다. 간략하게 1회독 한 것이라서 정확하지 않습니다. 요약을 차차 수정할 예정이니 내용을 파악하고 싶다면 논문을 직접 보시는 게 좋습니다. 1. 서론 아마존은 전세계급 서비스를 운용 이 논문에서는 Dynamo라 불리는 고가용성의 키벨류 저장소 시스템을 다룸 즉 always-on이 가능하게 하는 서비스임 토네이도 때문에 데이터 센터가 날아가거나 혹은 네트워크 장애가 발생하더라도 언제나 가용한 저장소 기술에 대한 니즈는 항상 있다. RDB의 일반적인 패턴은 비효율성을 가져왔다..

최근 Dynamo 논문을 읽어보면서 흥미로운 개념을 발견했다. 대부분의 DB의 경우 last writes wins라는 전략을 택한다고 한다. 간단하게 말하자면 마지막에 쓴 자가 기존 데이터를 덮어씌우는 방식이다. 동시 쓰기의 문제를 심플하게 나중에 쓴 사람 걸 채택하는 방식으로 해결한다는 것이다. 이렇게 하는 이유는 개발자의 편의에 있기도 하고, (개발자들은 본인의 client단에 복잡한 충돌 처리 로직을 작성하는 걸 싫어한다고 한다) 단순하게 그 방법이 가장 간단하기 때문이라고도 한다. 그런데 Dynamo 논문에서는 DynamoDB의 경우 last writes wins가 아니라 애플리케이션에서 해당 충돌에 대한 권한을 가질 수 있도록 만들었다고 한다. 즉 애플리케이션 단의 로직으로 해당 충돌 문제를 해..