- 2017/08/21 12:45
- sjc333.egloos.com/3206541
- 덧글수 : 4
트레이딩뷰 라는 사이트가 있습니다.
https://kr.tradingview.com
트레이딩뷰 이용 방법 https://steemit.com/kr/@sjc333/bscak
주식이나 가상화폐(암호화폐) 차트를 보는 사이트인데요.
거기에 각종 보조지표들이 있고, 또 그걸 이용자가 만들어서 사용할 수도 있더군요.
그리고 어떤 보조지표들은 유료입니다.
저도 프로그래머라서 트레이딩뷰(이하 트뷰)에서 제공하는 지표 만드는 언어를 익혀서 지표들을 만들어 보다가....
어느세 유료지표를 팔고 있습니다 ^^
신호등이라는 지표인데요
이렇게 생겼습니다.
저기서 중앙에 흰색 빨간색 녹색 등이 보이는 것이 신호등입니다.
https://kr.tradingview.com
트레이딩뷰 이용 방법 https://steemit.com/kr/@sjc333/bscak
주식이나 가상화폐(암호화폐) 차트를 보는 사이트인데요.
거기에 각종 보조지표들이 있고, 또 그걸 이용자가 만들어서 사용할 수도 있더군요.
그리고 어떤 보조지표들은 유료입니다.
저도 프로그래머라서 트레이딩뷰(이하 트뷰)에서 제공하는 지표 만드는 언어를 익혀서 지표들을 만들어 보다가....
어느세 유료지표를 팔고 있습니다 ^^
신호등이라는 지표인데요
이렇게 생겼습니다.
저기서 중앙에 흰색 빨간색 녹색 등이 보이는 것이 신호등입니다.
차트는 비트코인 한국KRW 차트입니다. 일봉이구요. 현재 471만원이군요.
제가 처음 살 때는 138만원 이였는데...와우!
신호등 자세한 내용, 구매법 : http://cafe.daum.net/whitestart/RpFe/10
이걸 만들어서 디시인사이드 가상화폐 갤러리에 한달간 홍보하고 며칠전부터 유료화 했습니다.
그랬더니 팔리고 있네요 ^^
프로그래밍을 배워서 돈을 이렇게도 벌고 저렇게도 벌고 있지만
지표를 만들어서 팔게될 날이 오다니 신기하군요.
저는 비트코인을 조금 사서 가지고 있는데 최근 500만원도 돌파한 적이 있어서 참 기분이 좋습니다.
거기다가 지표로도 돈을 벌고 있구요.
이걸 만들어서 디시인사이드 가상화폐 갤러리에 한달간 홍보하고 며칠전부터 유료화 했습니다.
그랬더니 팔리고 있네요 ^^
프로그래밍을 배워서 돈을 이렇게도 벌고 저렇게도 벌고 있지만
지표를 만들어서 팔게될 날이 오다니 신기하군요.
저는 비트코인을 조금 사서 가지고 있는데 최근 500만원도 돌파한 적이 있어서 참 기분이 좋습니다.
거기다가 지표로도 돈을 벌고 있구요.
신호등은 현재 무료버젼도 있으니 위 링크로 가셔서 한번 보시길 바랍니다 ^^
- 2017/07/24 10:27
- sjc333.egloos.com/3204963
- 덧글수 : 0
아래에 글을 다 쓰고 보니 스팀잇이 더 좋겠다는 생각을 가지게 되었습니다.
---
하지만 아래 글은 일단 남겨두겠습니다.
이글에 댓글을 달기보다, 위 스팀잇 포스트에 댓글을 달아주시면 제가 더 빨리 답글하겠습니다.
---
현재 트뷰 링크에 댓글은 너무 많아서 해당 지표 페이지가 너무 무거워젔습니다.
그리고 디시갤러리에 유료화 준비중인 지표에 대한 글이 자주 올라오는 것도 좋지 않다고 보입니다.
일단 임시로 여기 카테고리를 개설하였는데
저 외에는 댓글만 달 수 있다는 단점이 있네요.
적당한 게시판을 하나 개설할 수 있다면 참 좋겠는데 어디가 좋을지 모르겠습니다.
태그 : 신호등
- 2017/05/12 05:14
- sjc333.egloos.com/3201074
- 덧글수 : 2
하나의 파일을 처리하는 하나의 객체가 있다.
더 빨리 처리하기위해 파일을 a라고 하자, a파일을 n개의 영역으로 나누고, n개의 스레드에 각각 객체를 만들어서 영역을 배정했다.
(편의상 a파일을 그냥 파일이라고 부르기도 하겠다.)
각 스레드는 하나의 객체를 가지며, 그 객체는 그 스레드에서 자기 영역을 처리하면 된다.
추가 스레드에서 파일에 직접 접근하는 것은 아니다.
내가 아는한 a파일에 접근하는 것은 메인 스레드 뿐이다.
메인스레드가 a파일의 내용을 변수로 읽어 들이면, 객체들이 그 변수를 처리한다.
(a파일에 대한 읽기나 쓰기 권한을 가지는 것은 오직 메인스레드 뿐이다.)
우선 스레드를 생성하고, 스레드안에서 객체를 생성했다.
모든 스레드가 초기화가 끝나면, 메인스레드가 파일을 열고 읽어들여서 작업배정을 한다.
문제가 여기서 터졌다. 스레드를 한 20개정도 만들면 파일이 안열리는 것이다.
fstream이 파일을 열려고하면 Too many open files 에러를 출력한다. (ifstream 이든 ofstream 이든)
도무지 이해가 안갔다. 왜냐면 각 스레드에서 생성된 각각의 객체들은 내가 아는 바로는 (a가 아닌)파일을 열더라도 생성과정(초기화)이 끝나면 그 파일들을 닫기 때문이다.
----------------------------
너무 혼란스러워서 다양한 실험을 해보았다.
#우선 용어정리. 하나의 추가스레드와 그 안에서 생성된 객체를 묶어서 워커(작업자)라고 한다.
1. 워커를 8명 생성한 뒤에 a파일을 열면 잘 열린다. 쓰기용이든 읽기용이든 잘 열린다. (즉, 워커 자체가 그 파일에 대한 권한을 가지려고 하는 것은 아님이 증명됨)
2. 워커를 20명 생성한 뒤에 파일을 열려고하면 too many open files 에러
3. a파일을 미리 열고, 워커를 대량(20명이상) 생성한 다음에 파일을 닫는다. 그러면 워커들이 살아있는 동안에 다시 파일을 열 수 있다. (ifstream이든 ofstream이든)
워커를 생성하기 직전에, 그 파일을 열고 닫아버리면 워커 생성후에 열수 없다. 즉, 중요한 것은 워커들을 생성하기전에 열어두고, 생성이 완료될 때 까지 파일을 연 상태로 가지고 있어야 한다. 여기까지 도달하면 a파일을 닫고 다시 열 수도 있다.
4. 워커는 100명도 생성이 가능하다. 죽였다가 다시 100명을 생성할 수 있으며, 이 워커들은 모두 정상이다. 워커 생성은 언제든지 가능했으며, 얼마든지 가능했고, 항상 정상적인 워커들이였다.
5. 워커8명을 생성하고 파일을 열고 처리하고 닫고 워커를 죽인다. 즉 실험1번의 내용인데, 이 과정을 프로그램이 3번 반복하면 3번째부터 파일을 열지 못한다. 프로그램을 종료하고 다시 시작해야 가능해진다. (2번까지는 반복이 가능)
6. 파일을 열어두고 워커100명을 생성하고 파일을 닫고 다시 열어서 처리한다음 다시 닫는다. 그리고 워커를 다 죽인다. 이 과정을 여러번 반복하는 것은 가능하다. (이것은 실험3번을 반복하는 것) 과거에 아무리 많은 워커를 사용했더라도 다 죽어있기만 하면 파일을 열 수 있다는 것이다.
이것이 증명하는 것은, 워커가 생성될 때 혹여나 다른 파일들을 열었다 하더라도, 워커가 파괴될 때는 자기가 연 파일을 모두 닫는다는 것이다.
그렇지 않다면 워커 생성파괴를 수백번 반복한 뒤에는 그 어떤 파일도 열 수가 없게 될 것이다.
이걸 생각해보면, 5번 실험결과는 정말 이해하기 어렵다.
--------------------------------
여기서 밝히지만 그 워커...그러니까 그 객체...그 클래스 자체를 내가 코딩했다. 너무 방대한 소스코드여서 다 확신할 수는 없지만, 내가 알기로 추가 스레드에서 생성되는 객체는 따로 파일을 열지 않는다.
-------------------------------
그래서 파일을 열지 못하는 정확한 조건을 적자면 제법 복잡한데 ...아무튼 이렇다. 아래 조건을 모두 만족해야한다.
1. 이전에 워커를 생성했던 적이 대략 20번 정도 되어야 한다. 소량 생산하고 죽이기를 반복해도 되고, 한번에 대량 생산해도 이 조건을 만족할 수 있다. (16번 이하에서는 파일 열기 가능함)
2. 현재 살아있는 워커가 존재해야한다. (워커를 아무리 많이 생성했더라도 다 죽여서 현재 살아있는 워커가 없다면 파일을 열 수 있다.)
3. 그 파일을 미리 열어두고 워커를 생성한 것은 아니여야 한다. (살아있는 워커가 아무리 많아도, 그 파일이 이미 열려있었다면 언제든지 다시 닫고 열기가 가능하다. )
이렇게 3가지 조건을 모두 만족하면 파일을 열지 못한다.
내가 확신하는 것
1. 해당 파일에 대한 권한 문제는 아니다. 워커들은 결고 크 파일에 대한 권한에 관여하지 않는다.
2. 워커는 개별적으로 a가 아닌 다른 파일을 가질지는 몰라도 죽을 때는 분명히 다 닫는다. 스레드 또한 분명히 종료되고 join된다. 스레드간 자원 관리를 위한 뮤텍스 또한 분명히 해제된다.
내가 최종적으로 내린 문제의 원인
- 가질 수 있는 핸들(윈도우에서 사용하는 그것) 수의 문제인듯. 파일핸들은 스레드핸들이 너무 많이 생성되면 얻기가 힘든 것 같다. 스레드핸들이 많이 생성되었던 적이 있는 상태에서, 살아있는 추가 스레드가 존재한다면 새로운 파일핸들을 얻기가 힘들다는 것이다.
그러니까 내 나름의 결론은 내 소스코드의 잘못이라기 보다 운영체제에 뭔가 작동상 특이점이 있다는 것이다.
그냥 내가 알아서 잘 피해야겠다고 생각중....
근 몇일간 이 문제를 해결하기위해 수많은 노력을 기울였는데 참 허망하다.....그리고 아직도 나는 내가 코딩한 이 객체에 대한 믿음이 확실하지 않아서 답답하다. 솔직히 운영체제에 문제가 있다고 판단하다니..좀 이상하자나??? 그러나 실험결과들을 보면 아무리 생각해도 운영체제 문제같아....
최근 덧글