내용상 같은 문서 같은데..
왜 kernel.org 문서는 눈에 잘 안들어 올까?
오히려 과도한(?) 서식이 문제인가
[링크 : https://www.kernel.org/doc/html/v4.11/driver-api/iio/index.html]
| pthread 테스트 (0) | 2022.11.24 |
|---|---|
| pthread (0) | 2022.11.23 |
| mkpipe 와 poll (0) | 2022.10.26 |
| ‘F_SETPIPE_SZ’ undeclared (0) | 2022.10.20 |
| linux fifo (0) | 2022.10.18 |
가능은 한 것 같은데..
[링크 : https://stackoverflow.com/questions/15055065/o-rdwr-on-named-pipes-with-poll]
[링크 : https://man7.org/linux/man-pages/man3/mkfifo.3.html]
| Macro: int ENXIO“No such device or address.” The system tried to use the device represented by a file you specified, and it couldn’t find the device. This can mean that the device file was installed incorrectly, or that the physical device is missing or not correctly attached to the computer. |
[링크 : https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html]
+
2022.10.27
POLLIN으로 탐지가 되는 듯?
| $ cat rx.c //#define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <string.h> #include <linux/fcntl.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <errno.h> #include <sys/poll.h> #define FIFO_FILE "/tmp/fifo" #define BUFF_SIZE 1024*768*4 struct pollfd pfd[1]; int main(int argc, char** argv) { int ret = 0; int counter = 0; int fd; char buff[BUFF_SIZE]; // printf("argc[%d]\n",argc); if ( -1 == mkfifo( FIFO_FILE, 0666)){ perror( "mkfifo() 실행에러"); exit( 1); } if ( -1 == ( fd = open( FIFO_FILE, O_RDONLY|O_NONBLOCK))){ // <---- (A) perror( "open() 실행에러"); exit( 1); } ret = fcntl(fd, F_SETPIPE_SZ, 1024 * 1024); pfd[0].fd = fd; pfd[0].events = POLLIN; printf("fd[%d]ret[%d]\n",fd,ret); while( 1 ){ int n = poll(pfd, 1, 10); if (n > 0) { memset( buff, 0, BUFF_SIZE); ret = read( fd, buff, BUFF_SIZE); if(ret > 0 ) printf("ret[%d]\n",ret); // printf( "%d: %s\n", counter++, buff); } printf("."); usleep(10000); } close( fd); } |
| $ cat tx.c #include <stdio.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <unistd.h> #include <signal.h> #define FIFO_FILE "/tmp/fifo" int main_loop = 1; int write_loop = 1; void sigint_handler(int sig) { main_loop = 0; write_loop = 0; } void sigpipe_handler(int sig) { write_loop = 0; } int main(int argc, char **argv) { int fd; int fd_r; // char *str = "badayak.com"; char *str = NULL; char *temp = NULL; str = (char*)malloc(1024*768*4); temp = (char*)malloc(1024*768*4); memset(str, *argv[1], 1024*768*4); // signal(SIGPIPE, SIG_IGN); signal(SIGPIPE, &sigpipe_handler); signal(SIGINT, &sigint_handler); /* printf("%d\n",__LINE__); if ( -1 == mkfifo( FIFO_FILE, 0666)){ perror( "mkfifo() 실행에러"); exit( 1); } */ while(main_loop) { printf("%d\n",__LINE__); do { fd = open( FIFO_FILE, O_WRONLY | O_NONBLOCK); usleep(100000); printf("fd[%d] %d\n",fd,__LINE__); if(main_loop == 0 && write_loop == 0) exit(1); } while(fd == -1); write_loop = 1; int ret = 0; while(write_loop) { printf("%d\n",__LINE__); int a = write( fd, str, atoi(argv[1])); printf("%d a[%d]\n",__LINE__,a); usleep(1000000); } } close( fd); } |
| pthread (0) | 2022.11.23 |
|---|---|
| iio(industrial io) 문서 (0) | 2022.11.11 |
| ‘F_SETPIPE_SZ’ undeclared (0) | 2022.10.20 |
| linux fifo (0) | 2022.10.18 |
| SIGPIPE (0) | 2022.10.17 |
커널이 5.4.0 이라 그런가
해당 선언을 해주어야 에러가 사라진다.
| #define _GNU_SOURCE |
[링크 : https://stackoverflow.com/questions/25411892/f-setpipe-sz-undeclared]
|
Defining _GNU_SOURCE has nothing to do with license and everything to do with writing (non-)portable code. If you define _GNU_SOURCE, you will get:
In particular, the things from _GNU_SOURCE that you should never use are #2 and #4 above. |
[링크 : https://stackoverflow.com/questions/5582211/what-does-define-gnu-source-imply]
호환성 지정 매크로
[링크 : https://m.blog.naver.com/netiz21/150015716721]
#include <fcntl.h> 대신
#include <linux/fcntl.h> 하면 _GNU_SOURCE를 해주지 않아도 되긴 한데
다른데서 경고가 뜨니 알아서 써야 할 듯.
| /usr/include/linux/fcntl.h:28:#define F_SETPIPE_SZ (F_LINUX_SPECIFIC_BASE + 7) /usr/include/linux/fcntl.h:29:#define F_GETPIPE_SZ (F_LINUX_SPECIFIC_BASE + 8) |
| iio(industrial io) 문서 (0) | 2022.11.11 |
|---|---|
| mkpipe 와 poll (0) | 2022.10.26 |
| linux fifo (0) | 2022.10.18 |
| SIGPIPE (0) | 2022.10.17 |
| linux ipc 최대 데이터 길이 (0) | 2022.10.11 |
특이하다면 특이하고, 당연하다면 당연하게
fifo는 쓸 녀석과, 읽을 녀석이 둘다 요청이 들어올때 까지 open() 에서 blocking 된다.
strace를 이용해서 확인해보면 각각 실행할 경우
O_RDONLY를 주던 O_WRONLY를 주던 간에 open() 함수에서 block 되어있다
두개 프로그램이 read/write pair가 만들어지면 그제서야 open()을 넘어가게 된다.
open()을 non_block 으로 해서 name pipe의 pair가 만들어지길 기다리는 것도 방법 일 듯.
| $ strace ./rx openat(AT_FDCWD, "/tmp/fifo", O_RDONLY |
$ strace ./tx 2 openat(AT_FDCWD, "/tmp/fifo", O_WRONLY |
[링크 : https://tutorialspoint.dev/computer-science/operating-systems/named-pipe-fifo-example-c-program]
걍 이렇게 하고 나서 해보면 되려나?
| int fifo_fd = open(fifo_path, O_RDONLY | O_NONBLOCK); FILE *fp = fdopen(fifo_fd, "r"); |
[링크 : https://cboard.cprogramming.com/c-programming/89358-nonblocking-fifo.html]
| mkpipe 와 poll (0) | 2022.10.26 |
|---|---|
| ‘F_SETPIPE_SZ’ undeclared (0) | 2022.10.20 |
| SIGPIPE (0) | 2022.10.17 |
| linux ipc 최대 데이터 길이 (0) | 2022.10.11 |
| ipc 성능 비교 (0) | 2022.09.21 |
mkfifo()를 이용하여 named pipe를 해보는데
받는 쪽이 사라지니 보내는 애가 갑자기 에러도 없이 죽어
gdb로 확인해보니 SIGPIPE가 전달되었고 그로 인해서 프로세스가 종료 된 것으로 보인다.
| Program received signal SIGPIPE, Broken pipe. 0x00007ffff7af2104 in __GI___libc_write (fd=3, buf=0x7ffff76e1010, nbytes=3145728) at ../sysdeps/unix/sysv/linux/write.c:27 27 ../sysdeps/unix/sysv/linux/write.c: 그런 파일이나 디렉터리가 없습니다. |
[링크 : https://jacking75.github.io/linux_socket_sigpipe/]
gdb 에서 무시하게 하려면 아래의 명령어를 입력하라고 한다.
| handle SIGPIPE nostop pass pass |
| ‘F_SETPIPE_SZ’ undeclared (0) | 2022.10.20 |
|---|---|
| linux fifo (0) | 2022.10.18 |
| linux ipc 최대 데이터 길이 (0) | 2022.10.11 |
| ipc 성능 비교 (0) | 2022.09.21 |
| posix message queue (0) | 2022.09.21 |
ipc 타입에 따라 작다면 작고, 크다면 큰 용량이 할당되어 있다
pipe
| $ cat /proc/sys/fs/pipe-max-size 1048576 |
[링크 : https://unix.stackexchange.com/questions/11946]
uds (UNIX Domain Socket)
| $ cat /proc/sys/net/core/wmem_max 212992 |
[링크 : https://stackoverflow.com/questions/21856517]
message queue
| $ sysctl -a |grep kernel.msg kernel.msgmax = 8192 kernel.msgmnb = 16384 kernel.msgmni = 32000 |
| linux fifo (0) | 2022.10.18 |
|---|---|
| SIGPIPE (0) | 2022.10.17 |
| ipc 성능 비교 (0) | 2022.09.21 |
| posix message queue (0) | 2022.09.21 |
| zeroMQ (0) | 2022.09.20 |
zmq는 이런데서는 확 떨어지는 구나
Shared Memory > MQ > UDS > FIFO > Pipe > TCP 이런식인데
POSIX Message Queue가 생각외로 성능이 잘 나와서 놀랍다.
| IPC | Message rate |
| Pipe | 36539 msg/s |
| FIFOs (named pipes) | 26246 msg/s |
| Message Queue | 67920 msg/s |
| Shared Memory | 3821893 msg/s |
| TCP sockets | 22483 msg/s |
| Unix domain sockets | 40683 msg/s |
| ZeroMQ | 15414 msg/s |
| SIGPIPE (0) | 2022.10.17 |
|---|---|
| linux ipc 최대 데이터 길이 (0) | 2022.10.11 |
| posix message queue (0) | 2022.09.21 |
| zeroMQ (0) | 2022.09.20 |
| 파일 존재유무 확인하기 (0) | 2022.02.11 |
4세대 벤치에서는 mq가 udp sock보다 빠르다고
https://the-linux-channel.the-toffee-project.org/index.php?page=8-tutorials-research-socket-overhead-in-linux-vs-message-queues-and-benchmarking
| linux ipc 최대 데이터 길이 (0) | 2022.10.11 |
|---|---|
| ipc 성능 비교 (0) | 2022.09.21 |
| zeroMQ (0) | 2022.09.20 |
| 파일 존재유무 확인하기 (0) | 2022.02.11 |
| select, poll, epoll (0) | 2021.11.02 |
ZMQ 혹은 0MQ 라고도 쓰는것 같은데 접속 모델부터 좀 찾아 보는 중
REQ-REP는 단순(?)한 요청-응답 모델이고
PUB-SUB는 서버에 의한 broadcast 모델 pipeline은 아직 모르겠다.
| REQuest-REPly PUBlisher - SUBscriber PUSH- PULL (pipeline) |
[링크 : https://soooprmx.com/zmq의-기본-개념들/]
[링크 : https://makersweb.net/opensource/19422]
[링크 : https://zeromq.org/]
| Figure 2 - Request-Reply | Figure 4 - Publish-Subscribe | Figure 5 - Parallel Pipeline |
 |
 |
 |
| Figure 6 - Fair Queuing | ||
 |
[링크 : https://zguide.zeromq.org/docs/chapter1/]
| Shared Queue (DEALER and ROUTER sockets) In the Hello World client/server application, we have one client that talks to one service. However, in real cases we usually need to allow multiple services as well as multiple clients. This lets us scale up the power of the service (many threads or processes or nodes rather than just one). The only constraint is that services must be stateless, all state being in the request or in some shared storage such as a database. |
[링크 : https://zguide.zeromq.org/docs/chapter2/]
| Request-Reply Combinations We have four request-reply sockets, each with a certain behavior. We’ve seen how they connect in simple and extended request-reply patterns. But these sockets are building blocks that you can use to solve many problems. These are the legal combinations: REQ to REP DEALER to REP REQ to ROUTER DEALER to ROUTER DEALER to DEALER ROUTER to ROUTER |
[링크 : https://zguide.zeromq.org/docs/chapter3/]
Messaging PatternsUnderneath the brown paper wrapping of ZeroMQ’s socket API lies the world of messaging patterns. ZeroMQ patterns are implemented by pairs of sockets with matching types.The built-in core ZeroMQ patterns are:
|
| XPUB socket Same as PUB except that you can receive subscriptions from the peers in form of incoming messages. Subscription message is a byte 1 (for subscriptions) or byte 0 (for unsubscriptions) followed by the subscription body. Messages without a sub/unsub prefix are also received, but have no effect on subscription status. |
| XSUB socket Same as SUB except that you subscribe by sending subscription messages to the socket. Subscription message is a byte 1 (for subscriptions) or byte 0 (for unsubscriptions) followed by the subscription body. Messages without a sub/unsub prefix may also be sent, but have no effect on subscription status. |
[링크 : https://zeromq.org/socket-api/]
| int zmq_device (int device, const void *frontend, const void *backend); ZMQ_QUEUE starts a queue device ZMQ_FORWARDER starts a forwarder device ZMQ_STREAMER starts a streamer device Queue device ZMQ_QUEUE creates a shared queue that collects requests from a set of clients, and distributes these fairly among a set of services. Requests are fair-queued from frontend connections and load-balanced between backend connections. Replies automatically return to the client that made the original request. This device is part of the request-reply pattern. The frontend speaks to clients and the backend speaks to services. You should use ZMQ_QUEUE with a ZMQ_XREP socket for the frontend and a ZMQ_XREQ socket for the backend. Other combinations are not documented. Refer to zmq_socket(3) for a description of these socket types. Forwarder device ZMQ_FORWARDER collects messages from a set of publishers and forwards these to a set of subscribers. You will generally use this to bridge networks, e.g. read on TCP unicast and forward on multicast. This device is part of the publish-subscribe pattern. The frontend speaks to publishers and the backend speaks to subscribers. You should use ZMQ_FORWARDER with a ZMQ_SUB socket for the frontend and a ZMQ_PUB socket for the backend. Other combinations are not documented. Refer to zmq_socket(3) for a description of these socket types. Streamer device ZMQ_STREAMER collects tasks from a set of pushers and forwards these to a set of pullers. You will generally use this to bridge networks. Messages are fair-queued from pushers and load-balanced to pullers. This device is part of the pipeline pattern. The frontend speaks to pushers and the backend speaks to pullers. You should use ZMQ_STREAMER with a ZMQ_PULL socket for the frontend and a ZMQ_PUSH socket for the backend. Other combinations are not documented. Refer to zmq_socket(3) for a description of these socket types. |
| ipc 성능 비교 (0) | 2022.09.21 |
|---|---|
| posix message queue (0) | 2022.09.21 |
| 파일 존재유무 확인하기 (0) | 2022.02.11 |
| select, poll, epoll (0) | 2021.11.02 |
| Unhandled fault: external abort on non-linefetch (0) | 2021.05.25 |
tmpfs에 touch로 파일을 생성/삭제하면서 테스트 해보니
마우스 이벤트에 묶여있어도 cpu 점유율 이 크게 오르지 않는걸 봐서는 부하가 크지 않은 듯.
| if( access( fname, F_OK ) == 0 ) { // file exists } else { // file doesn't exist } |
[링크 : https://stackoverflow.com/questions/230062/whats-the-best-way-to-check-if-a-file-exists-in-c]
| #include <unistd.h> int access(const char *pathname, int mode); The mode specifies the accessibility check(s) to be performed, and is either the value F_OK, or a mask consisting of the bitwise OR of one or more of R_OK, W_OK, and X_OK. F_OK tests for the existence of the file. R_OK, W_OK, and X_OK test whether the file exists and grants read, write, and execute permissions, respectively. |
[링크 : https://linux.die.net/man/2/access]
| F_OK 파일 존재여부 R_OK 파일 read 퍼미션 여부 W_OK 파일 write 퍼미션 여부 X_OK 파일 execute 퍼미션 여부 |
| posix message queue (0) | 2022.09.21 |
|---|---|
| zeroMQ (0) | 2022.09.20 |
| select, poll, epoll (0) | 2021.11.02 |
| Unhandled fault: external abort on non-linefetch (0) | 2021.05.25 |
| Stopped (tty input) (0) | 2021.05.21 |
|
