실행을 눌렀다가 Python 환경을 준비하는 동안 중지를 누를 수 있다. 아직 프로세스가 없다는 이유로 중지 요청을 버리면 준비가 끝난 뒤 새 프로세스가 생길 수 있다. 나는 시작 중이라는 상태도 중지할 수 있어야 한다고 보고 기다림 뒤의 실행 경계에서 취소 상태를 다시 확인했다.

중지는 현재 프로세스에만 붙는 명령이 아니다

shutdown은 먼저 cancelled를 표시한다. 아직 kernel이 없으면 기다릴 completion이 있는지 확인하고 돌아간다. 프로세스 핸들이 없다고 중지의 의도 자체를 없애지는 않는다. run이 준비 중일 때도 이후 시작 경로가 이 값을 읽을 수 있어야 한다.

반대로 사용자가 새 실행을 명시적으로 시작하면 run의 새 수명에서 취소 값을 초기화한다. 과거 중지를 영원히 남겨 아무 일도 못 하게 하려는 구조는 아니다. 나는 새 의도로 시작한 실행과 옛 준비 작업의 늦은 복귀를 구분했다. 같은 불리언이어도 어느 실행에서 바뀌는지 설명이 필요했다.

환경을 기다린 다음 spawn 전에 다시 검사한다

start는 기존 커널 정리 뒤 취소 여부를 확인하고, 노트북을 읽고 Python 실행기 준비를 기다린 뒤 다시 검사한다. runtime 파일을 준비한 뒤와 로컬 서버가 listen을 마친 뒤에도 검사 지점이 있다. 중간 await 동안 사용자의 의도가 바뀔 수 있기 때문이다.

검사를 함수 맨 위에만 두면 기다리는 동안 들어온 중지는 놓친다. 반대로 자식 프로세스를 만든 뒤에야 취소를 알면 불필요한 실행과 정리를 이미 시작한 셈이다. 나는 비동기 준비 결과가 돌아왔다는 사실을 실행 허가로 해석하지 않으려 했다. 준비의 성공과 계속할 의사는 다른 조건이다.

준비 중이라는 표시도 busy의 일부다

run은 문서를 읽기 전 operating을 켠다. 커널이 아직 생성되지 않았어도 다른 실행을 겹쳐 넣지 않게 하는 상태다. 초기 load가 실패하면 이 값을 정리하고, 실행 경로의 finally에서도 화면 갱신과 completion 정리를 수행한다. 프로세스 유무 하나로 전체 시작 상태를 표현하지 않는다.

이 표시가 모든 종료 경합을 증명하는 것은 아니다. 실제로 어떤 await에서 멈췄는지와 그 뒤 어떤 부작용이 가능한지 봐야 한다. 나는 “busy가 false가 됐다”는 결과만큼 새 프로세스가 생기지 않았는지 확인하는 것이 중요하다고 생각했다. 화면이 한가해 보여도 늦은 실행이 남으면 중지는 끝난 것이 아니다.

시험은 기다리는 위치를 고정해서 만든다

기존 시험은 Python 준비 함수에 gate를 넣어 멈춘 뒤 shutdown을 요청하고 gate를 푼다. 실행기 이름은 실행되면 안 되는 sentinel로 둔다. 결과는 busy가 거짓이고 중지 문구가 남으며 kernel이 없어야 한다. 두 번째 시험은 초기 notebook load를 같은 방식으로 지연한다.

이는 타이밍이 우연히 맞기를 기다리는 시험보다 어떤 순서에서 중지가 들어왔는지 명확하다. 두 시험이 확인한 것은 환경 준비와 문서 로드의 특정 경계다. 자식 생성 뒤 모든 ready 메시지의 경합과 모든 운영체제를 전수 검수했다는 근거로 확대하지 않는다. 시험의 작은 성공을 정확히 남긴다.

준비 취소는 실제 외부 행동의 복구와 다르다

이 두 상황에서는 아직 시작하면 안 되는 실행을 막는 것이 목표다. 이미 브라우저에 전달된 변경의 결과를 되돌리는 시험이 아니다. 원장이 필요한 상황과 준비 중 취소만으로 끝나는 상황은 다르다. 이전 외부 결과가 미확정이면 그 결과를 먼저 읽어야 한다는 규칙도 그대로 남는다.

이번 콘텐츠 작업은 원래 시험을 새로 돌리거나 사용자 커널을 종료하지 않았다. 함수와 기존 gate 시험을 읽어 제작 판단을 정리했다. 공유 파일 원장의 저장·재열기 시험과도 별개의 근거다. 무엇이 시작되지 않았는지와 무엇이 이미 시작됐는지를 나눠 설명해야 중지 기능의 한계를 이해할 수 있다.

뒤늦은 성공이 사용자의 현재 의사를 이기지 않는다

환경 설치와 파일 읽기는 성공했을 수 있다. 그래도 사용자가 중지를 요청했다면 그 성공이 새 실행을 강요해서는 안 된다. 나는 비동기 함수의 결과를 받는 순간 현재 조건을 다시 묻는 습관이 작은 프로그램에서도 중요하다고 본다.

회사 프로그램에서 자료를 불러오다 화면을 닫거나 대상을 바꾸는 경우도 비슷하다. 늦게 온 자료를 이전 목적지에 그대로 적용하지 않아야 한다. 시작과 취소를 깊게 다루는 일은 예외 문장을 늘리는 것보다 늦게 도착한 결과가 누구의 현재 작업에 속하는지 확인하는 일이었다.