사무실 어항 청소

사무실 내 책상에 있는 20큐브~ 오랜만에 청소해줬다. 지난 가을 건조해지기 시작하면서 가습기 대신 내 책상의 습도조절을 위해서 셋팅한 조그만 수조다. 이 수조를 시작으로 사무실에서 책상에 미니 수조를 놓는 것이 유행처럼 퍼져버렸고 이제는 책상에 어항을 가지고 있는 사람도 제법 많은 편이다. 수조 속에 살고 있는 생물은 스칼렛 바디스 2마리, 우렁이 2마리, 야마토 새우 2마리, 스노우볼 5마리 끝~ 

사무실 책상 위에 20큐브~ 컴퓨터 작업에 찌들어 있는 현대인에게 있어서 마음의 안식처도 되고 습도조절도 되고 정말 좋은 선택이었던 것 같다.

하늘공원 억새축제

하늘공원 억새축제에 다녀왔다. 사람 반, 억새 반 게다가 지칠 줄 모르는 꼬맹이 아들 때문에 다리도 아프고 했지만 가을을 느낄 수 있어 기분전환도 되고 좋았다~ 이제 단풍도 보러 가야 하는데 어디로 갈까.. 흠~

킹크랩 붐?

아들이 꽃게가 먹고싶다고 해서 강서수산시장에 꽃게를 사러갔다. 최근 언론에서 킹크랩 가격이 폭락했다는 기사도 많이 봤고 지금 킹크랩을 먹어야 한다는 말도 많이 들었는데... 정말 가계 풍경은 말이아니었다.
킹크랩을 사러온사람들이 너무 많아서 킹크랩을 사기 위해 줄을 서있는 모습 -_-;; 이런 진풍경은 난생 처음 본듯.. 최근 언론에서 키로에 35,000원 까지 떨어졌다 했느데 주말이고 사람들도 많이 몰려서 그런지 가격이 조금 올라서 키로에 40,000원인 상태였음.

여튼 우리는 꽃게가 목적이었기 때문에 꽃게를 사려고 보니 킹크랩을 들여오려고 그랬는지 꽃게가 몇마리 없는게 영~ 사기 싫어지는 모습인 관계로 그냥 우리는 맘을 바꿔서 ~ 대세에 합류!! 그냥 킹크렙을 사버렸다.
2키로가 조금 넘는 놈을 골라서 97,000원~ 역시 싸기는 싸구나~ 하는 생각을 하고 집에가서 먹게 쪄달라고 했더니 -_-;;; 쪄가는게 1시간40분을 대기해야 한다고 해서 그냥 집에 가져와서 쪄버렸다 ㅎㅎ

급하게 웹검색을 해서 찾은 정보대로30분찌고 5분 뜸들였음~ 그러고는 냠냠~^^

리눅스에서 시그널 동작 방식

평소에 user level이 아닌곳에서 주로 작업을 하다보니 가끔 시그널을 사용할 때마다 헷갈리는 일이 생긴다.. ㅠ_ㅠ
뭐.. 잘 사용안하기 때문에 까먹는 것도 있지만.. 이 시그널이라는 놈이 막상 문서로 공부를 하다보면 좀 애매한 부분이 많아서.. -_-;; 평소에 익숙한 커널코드에서 어떻게 동작하는지 파악을 하고 평소에 애매하게 생각되는 부분을 확실하게 정리하기로 했다.

우선 시그널을 발생시키는 부분부터 알아보면, 특정 프로세스에게 signal을 전달 하게 될 경우 signal은 수신 대상 프로세스의 task structure에 signal을 저장하는 queue로 전달되고 저장 되면서 전달 작업은 모두 종료하게 된다.

그리고 시그널의 실행을 알아보면, 프로세스는 시스템콜, 인터럽트 등등 여러가지 이유로 Kernel모드에 진입했다가 유저모드로 복귀하기전에 do_signal 커널API를 실행하게 되며 do_signal()는 task structure의 queue에서 signal을 하나 꺼낸 다음 signal에 대한 처리를 수행한다.

signal 처리를 수행 하는 방법은 프로세스가 user모드와 kernel모드로 변경되는 과정에서 프로세스의 실행에 관련된 모든 정보를 저장하는 pt_regs의 정보를 조작하는 방법으로 수행이 된다.
kernel모드에서 user모드로 복귀하는 과정을 살펴 보면 kernel모드로 진입하면서 저장해둔 pt_regs정보를 CPU레지스터에 복원하면서 프로세스는 kernel모드에 진입하기 직전상태에 이어서 계속적으로 로직을 수행할수 있는 것이다.
그리고 do_signal()은 user모드로 복귀하기 직전에 수행이 되면서 user모드로 복귀하자마자 signal handler가 호출될수 있도록 pt_regs정보를 수정하게 되며 이로 인하여 signal handler는 자연스럽게 프로세스가 복원되야하는 지점에서 호출된 함수처럼 동작하고 return을 하면서 원래 프로세스가 수행하려던 로직으로 복귀를 하게된다.

일단 signal이 동작하는 방식은 대충 이해했으니.. 이 정보를 기반으로 pending, block, ignore의 동작 방식을 정리해보자.

pending
task structure의 queue에 signal이 달려있으나  아직 do_signal()이 signal를 안 꺼낸 상태(즉 signal을 받았으나 아직 실행전)를 의미하며 만약 동일한 signal이 또 발생시 queue를 검사해서 동일한 signal이 존재하면 pending상태로 보고 queue에 넣은 과정을 생략하고 폐기하게 된다. queue에는 동일 signal이 1개만 pending될 수 있다.

block
task structure의 queue에 있는 signal을 실행하기 위해서 꺼내는 과정 중 block 비트가 켜진 시그널은 queue에 그냥 두고 block 비트가 없는 시그널중에 가장 앞에있는 것을 꺼낸다. 결과적으로 block이 풀릴때 까지 해당signal은 queue에 머물수 밖에 없으며 이로 인하여 pending상태가 유지된다.

ignore
task structure의 queue에서 signal을 꺼내고 ignore bit가 켜진 시그널이면 그냥 버린다.


시그널 handler가 수행중이라면 ?
시그널 handler가 실행되기 직전에 do_signal()에 의해서 해당 signal에 상태를 block으로 바꾸고 user모드로 진입하기 때문에 handler가 실행중일때 동일한 시그널이 들어오면 자연스럽게 Block과 동일하게 동작을 하며 이로인하여 동일한 시그널은 1개만 pending이 되는것이다.
* 만약 SA_NODEFER옵션이 있을 경우 handler 실행 전에 block으로 바꾸는 행위는 하지 않음. handler가 수행중일 지라도 동일한 시그널이 치고 들어올수 있음.