Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

0MQ guide bug: missing functions in zhelpers.h #3

Closed
dlintw opened this issue Sep 11, 2010 · 2 comments
Closed

0MQ guide bug: missing functions in zhelpers.h #3

dlintw opened this issue Sep 11, 2010 · 2 comments

Comments

@dlintw
Copy link

dlintw commented Sep 11, 2010

in chapter 1, it introduce zhelpers.h.
in chapter 2,3, it use other functions z_dump, z_sendmore which is not showed in chapter 1's zhelpers.h.

So, I suggest, the full zhelpers.h should suggest guide readers to download from
http://github.com/imatix/zguide/raw/master/examples/C/zhelpers.h

In last chapter 2, syncpub.c sleep(1) is not enough for me on my eee pc. So, I suggest, change it to function which could detect when will all data sent.
@dlintw
Copy link
Author

dlintw commented Sep 13, 2010

zhelpers.h exist bug, here is the compiler warning

92 // Dump the message as text or binary
93 char *data = zmq_msg_data (&message);
94 int size = zmq_msg_size (&message);
95 int is_text = 1;
96 int char_nbr;
97 for (char_nbr = 0; char_nbr < size; char_nbr++)
98 if (data [char_nbr] < 32 || data [char_nbr] > 127)
99 is_text = 0;

Line 98: warning: comparison is always false due to limited range of data type

@hintjens
Copy link
Contributor

Done, thanks.

rfarnham added a commit to rfarnham/zguide that referenced this issue May 22, 2020
@rfarnham
Set both pipefds[0] and pipefds[1] to O_NONBLOCK
e309eee 
It is important to set both ends of the self pipe as nonblocking, otherwise
the signal handler might block on the `write` call  and the process will deadlock.
Example:
```
(lldb) bt
* thread booksbyus#1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff5f09ff46 libsystem_kernel.dylib`write + 10
    frame booksbyus#1: 0x000000010f8f9cd2 interrupt`s_signal_handler(signal_value=2) at interrupt.c:20:12
    frame booksbyus#2: 0x00007fff5f152b5d libsystem_platform.dylib`_sigtramp + 29
    frame booksbyus#3: 0x000000010f8f981a interrupt`burn_cpu at interrupt.c:44:3
    frame booksbyus#4: 0x000000010f8f9b60 interrupt`main at interrupt.c:114:23
    frame booksbyus#5: 0x00007fff5ef673d5 libdyld.dylib`start + 1
    frame booksbyus#6: 0x00007fff5ef673d5 libdyld.dylib`start + 1
(lldb) f 1
frame booksbyus#1: 0x000000010f8f9cd2 interrupt`s_signal_handler(signal_value=2) at interrupt.c:20:12
   17  	#define S_ERROR_MSG "Error while writing to self-pipe.\n"
   18  	static int s_fd;
   19  	static void s_signal_handler(int signal_value) {
-> 20  	  int rc = write(s_fd, S_NOTIFY_MSG, sizeof(S_NOTIFY_MSG));
   21  	  if (rc != sizeof(S_NOTIFY_MSG)) {
   22  	    write(STDOUT_FILENO, S_ERROR_MSG, sizeof(S_ERROR_MSG) - 1);
   23  	    perror("error writing\n");
```

Original code was buggy, as it did not use the loop variable `i`:
```
    for (int i = 0; i < 2; i++) {
        int flags = fcntl(pipefds[0], F_GETFL, 0);
        if (flags < 0) {
            perror ("fcntl(F_GETFL)");
            exit(1);
        }
        rc = fcntl (pipefds[0], F_SETFL, flags | O_NONBLOCK);
        if (rc != 0) {
            perror ("fcntl(F_SETFL)");
            exit(1);
        }
    }
```
The loop was erroneously removed in this commit booksbyus@aebc4b5
rfarnham added a commit to rfarnham/zguide that referenced this issue May 22, 2020
@rfarnham
Set both pipefds[0] and pipefds[1] to O_NONBLOCK
cb6dde9 
It is important to set both ends of the self pipe as nonblocking, otherwise
the signal handler might block on the `write` call  and the process will deadlock.
Example:
```
(lldb) bt
* thread booksbyus#1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff5f09ff46 libsystem_kernel.dylib`write + 10
    frame booksbyus#1: 0x000000010f8f9cd2 interrupt`s_signal_handler(signal_value=2) at interrupt.c:20:12
    frame booksbyus#2: 0x00007fff5f152b5d libsystem_platform.dylib`_sigtramp + 29
    frame booksbyus#3: 0x000000010f8f981a interrupt`burn_cpu at interrupt.c:44:3
    frame booksbyus#4: 0x000000010f8f9b60 interrupt`main at interrupt.c:114:23
    frame booksbyus#5: 0x00007fff5ef673d5 libdyld.dylib`start + 1
    frame booksbyus#6: 0x00007fff5ef673d5 libdyld.dylib`start + 1
(lldb) f 1
frame booksbyus#1: 0x000000010f8f9cd2 interrupt`s_signal_handler(signal_value=2) at interrupt.c:20:12
   17  	#define S_ERROR_MSG "Error while writing to self-pipe.\n"
   18  	static int s_fd;
   19  	static void s_signal_handler(int signal_value) {
-> 20  	  int rc = write(s_fd, S_NOTIFY_MSG, sizeof(S_NOTIFY_MSG));
   21  	  if (rc != sizeof(S_NOTIFY_MSG)) {
   22  	    write(STDOUT_FILENO, S_ERROR_MSG, sizeof(S_ERROR_MSG) - 1);
   23  	    perror("error writing\n");
```

Original code was buggy, as it did not use the loop variable `i`:
```
    for (int i = 0; i < 2; i++) {
        int flags = fcntl(pipefds[0], F_GETFL, 0);
        if (flags < 0) {
            perror ("fcntl(F_GETFL)");
            exit(1);
        }
        rc = fcntl (pipefds[0], F_SETFL, flags | O_NONBLOCK);
        if (rc != 0) {
            perror ("fcntl(F_SETFL)");
            exit(1);
        }
    }
```
The loop was erroneously removed in this commit booksbyus@aebc4b5
@PoincareX PoincareX mentioned this issue Apr 24, 2022
Open
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hintjens @dlintw