ref.listen — Provider 값이 바뀔 때 "화면을 움직이고" 싶다면먼저 하나 짚고 갈게. ref.listen은 Provider 타입이 아니야. StreamProvider, FutureProvider처럼 뭔가를 새로 만드는 게 아니라, 이미 있는 Provider의 값 변화를 감지만 하는 메서드야. 아래 코드에서도 listenProvider라는 이름을 썼지만, 실제로는 그냥 평범한 StateProvider야.import 'package:flutter_riverpod/flutter_riverpod.dart';// 그냥 StateProvider를 하나 선언한 것뿐 - 이름이 listenProvider라고 특별한 게 아님final listenProvider = StateProvider((ref) =>..
Programming/[ Flutter ]2026. 7. 16. 01:06
[Flutter] 플러터 #12 - AutoDispose
화면 나가도 안 사라지던 그 Provider — AutoDispose지난 글에서 StreamProvider 봤을 때, 스트림 구독이 화면 나가도 계속 살아있다고 했잖아. 사실 이건 StreamProvider만의 문제가 아니야 — Riverpod의 Provider는 기본적으로 한 번 만들어지면 앱이 끝날 때까지 안 사라져. 아무도 안 보고 있어도 계속 메모리에 남아있는 거야. 이걸 해결하는 게 .autoDispose야.AutoDispose가 뭐야Provider가 더 이상 쓰이지 않을 때 알아서 없어지게 해주는 옵션이야. 별도의 클래스가 아니라, 기존 Provider 뒤에 .autoDispose를 하나 붙이는 것만으로 켤 수 있는 기능이야.Provider 생명주기를 생각해보면 이래. 원래 Provider는 ..
Programming/[ Flutter ]2026. 7. 16. 01:00
[Flutter] 플러터 #11 - StreamProvider
FutureProvider 다음은 StreamProvider — 계속 흘러오는 데이터는 어떻게 다뤄?FutureProvider 쓸 때 state.when(data, error, loading)으로 비동기 상태 처리했던 거 기억나지? StreamProvider도 똑같은 패턴이야. 다른 점 딱 하나만 이해하면 돼 — Future는 값을 한 번 주고 끝이고, Stream은 값을 계속 흘려보내.Future랑 Stream, 뭐가 다른데StreamProvider는 이 Stream을 감싸서 UI가 편하게 구독할 수 있게 해주는 Provider야. 이걸 쓰면 좋은 점이 몇 가지 있어.스트림 관리가 편해져: 스트림 상태·데이터 변화를 감지하고, 그때그때 UI를 알아서 업데이트해줘여러 위젯이 같은 데이터를 공유해: 스트림..
Study/[ OS ]2026. 7. 15. 20:08
#17 가상메모리와 요구 페이징, 페이지 교체
프로세스 전체를 안 올려도 실행이 된다고? — 가상메모리와 요구 페이징가상메모리가 실제로 뭘 해결하는 기술인지, 요구 페이징이 어떻게 필요한 것만 골라서 올리는지, 페이지 폴트가 터지면 내부에서 정확히 무슨 일이 일어나는지, 그리고 메모리가 꽉 찼을 때 어떤 페이지를 빼낼지 정하는 알고리즘들까지 알아보자!지금까지 주소 변환, 세그멘테이션, 페이징, TLB, Multi-level Page Table을 쭉 봐왔는데, 이 모든 걸 관통하는 마지막 조각이 바로 가상메모리야. 지금까지는 "필요한 페이지는 항상 메모리에 있다"고 가정했는데, 이제 그 가정을 깰 차례야.프로세스 전체는커녕, 지금 당장 필요한 부분만 메모리에 올려놓고 나머지는 디스크에 던져놓은 채로도 프로그램이 잘 돌아가.가상메모리가 뭐야실제 물리 메..
Study/[ OS ]2026. 7. 15. 19:19
#16 Paging: Smaller Table
Page Table이 4MB라고? 이걸 어떻게 줄여 — Smaller Table지난 글에서 TLB가 관리할 수 있는 page 수보다 프로세스가 훨씬 많은 page를 요구하는 상황이 있다고 했잖아. 이럴 때 문제는 TLB만이 아니야 — Page Table 자체가 너무 커져서 메모리를 잡아먹는 문제가 따로 있어. 이걸 줄이는 방법들을 하나씩 보자.문제부터: Page Table이 왜 이렇게 커TLB가 감당할 수 있는 것보다 훨씬 많은 page를 요구하는 프로세스는 흔해. 이런 프로세스의 Page Table 크기를 실제로 계산해보자.4KB(2^12) 크기의 page랑 4바이트 크기의 Page Table Entry를 쓰는 32비트 가상 주소 공간이 있다고 하면: Page Table 크기 = (가상 주소 공간 크기..
Study/[ OS ]2026. 7. 15. 18:53
#15 변환참조버퍼 TLB _ 심화편
TLB, 실제로 얼마나 빨라지는 건데? — 숫자로 보는 TLB 심화TLB가 정확히 왜 필요한지, VPN·PFN이 실제로 어떻게 캐싱되는지, 지역성 덕분에 TLB hit rate가 왜 높아지는지, Context Switching이 왜 문제고 ASID가 어떻게 해결하는지, 그리고 TLB가 꽉 찼을 때 뭘 빼내는지까지 숫자로 직접 확인해볼게.Paging의 오버헤드, 다시 짚고 가기Paging으로 메모리를 가상화하면 메모리 접근 하나당 두 번의 작업이 필요해. Page Table에 한 번 접근하고, 거기서 얻은 정보로 실제 메모리에 또 한 번 접근하는 거야. 이 두 번째 접근이 매번 따라붙으니까 느려질 수밖에 없어. 이걸 빠르게 만들려고 나온 게 TLB야.TLB가 뭐야TLB는 MMU의 일부분이자, 주소 변환을 ..
Study/[ OS ]2026. 7. 15. 01:47
#14 변환참조버퍼 TLB _ 기본편
매번 Page Table 뒤지면 너무 느리잖아 — TLB오늘 이 글에서는 TLB가 정확히 뭘 캐싱하는 건지, TLB 안에 뭐가 들어있는지, 그리고 TLB 하나 때문에 속도가 얼마나 차이 나는지까지. 딱 기본만 다루고, 더 깊은 내용은 다음 글(TLB 심화)에서 이어갈게.지난 글에서 페이징의 문제로 "메모리 접근마다 Page Table을 한 번 더 읽어야 한다"는 걸 짚었잖아. 이 추가 접근을 없애려고 나온 게 TLB야.TLB가 뭐야Translation Lookaside Buffer의 약자야. 번역하면 변환참조버퍼, 변환우선참조버퍼, 변환색인버퍼 이렇게도 불리는데 다 같은 걸 가리켜. 한마디로 정리하면, Page Table을 캐싱해두는 저장 장치야. CPU 캐시가 메모리 접근을 빠르게 해주는 것처럼, TL..
Study/[ OS ]2026. 7. 15. 01:33
#13 페이징 (Paging)
프로세스를 16바이트씩 잘라서 아무데나 흩뿌린다고? — 페이징지난 글에서 세그멘테이션이 외부 단편화라는 숙제를 남겼다고 했잖아. 그 숙제를 푸는 방법이 페이징이라고 했던 것까지 기억해? 아이디어는 단순해 — 세그먼트처럼 가변 크기로 나누지 말고, 아예 처음부터 똑같은 크기로 잘라버리자는 거야.페이징이 뭐야Paging은 프로세스의 가상 주소 공간을 고정 크기(fixed-size)로 잘라서 메모리에 할당하는 방식이야. 이 고정 크기 단위를 가상 주소 공간에서는 page라고 부르고, 이 page가 실제 메모리에 할당되는 자리를 page frame이라고 불러. 정리하면, 가상 쪽에서는 page, 물리 쪽에서는 frame — 이름만 다르지 크기는 완전히 똑같아.페이징의 장점유연성(Flexibility)주소 공간을..
Study/[ OS ]2026. 7. 15. 01:11
#12 Segmentation
힙이랑 스택 사이, 그 텅 빈 공간은 왜 낭비될까 — 세그멘테이션base·bound 방식 하나로는 왜 메모리가 낭비되는지, 세그멘테이션이 그 문제를 어떻게 푸는지, 그리고 세그먼트별로 주소를 어떻게 변환하는지, 마지막으로 세그멘테이션이 낳는 새로운 문제(외부 단편화)까지 이 글로 같이 공부해보자!기존 방식이 왜 비효율적일까지난 글에서 본 base·bound 방식은 가상 주소 공간 전체를 물리 메모리에 통째로 하나의 덩어리로 배치했어. 근데 프로세스의 주소 공간을 들여다보면 Code, Heap은 아래쪽에 있고 Stack은 위쪽에 있고, 그 사이는 텅 비어있잖아. 이 방식은 이 텅 빈 부분까지도 물리 메모리에 자리를 잡아버려. 문제가 세 가지 생겨.안 쓰는 공간까지 자리를 차지하니까 메모리가 낭비돼주소 공간..
