[9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
Hi all,
I am trying such simple program:
#include u.h
#include libc.h
static void
closer(int dfd) {
print(closer(%d): 1\n, getpid());
sleep(10 * 1000);
print(closer(%d): 2\n, getpid());
close(dfd);
print(closer(%d): 3\n, getpid());
}
void
main(int, char**)
{
int dfd;
char ddir[NETPATHLEN];
char buf[1024];
long nr;
print(main (%d): 1\n, getpid());
dfd = dial(tcp!192.168.8.61!23, nil, ddir, nil);
if (dfd 0)
sysfatal(dial: %r);
print(main (%d): 2\n, getpid());
switch (rfork(RFPROC|RFREND|RFMEM)) {
case -1:
sysfatal(fork: %r);
case 0:
closer(dfd);
break;
default:
for (;;) {
print(main (%d): 3\n, getpid());
nr = read(dfd, buf, sizeof buf);
print(main (%d): 4\n, getpid());
if (nr = 0)
break;
}
print(main (%d): 5\n, getpid());
close(dfd);
break;
}
exits(nil);
}
I want to have one process waiting in 'read' function on opened TCP
connection.
I want to close such a TCP connection from another process (created with
shared file descriptor table).
I would expect that 'read' function is finished with -1...
...but it is not.
Here is the output of the program:
main (2): 1
main (2): 2
closer(3): 1
main (2): 3
main (2): 4
main (2): 3
closer(3): 2
closer(3): 3
You can see that 'main' process is still pending in 'read' function on
already closed 'fd'.
Do I really have to use notes to release the pending 'main' in 'read' call?
Pavel
Re: [9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
Hi cinap, hangup(cfd);/* hangup connection, fd stays valid but i/o will error */ thank you for your explanation and help. Going to use 'hangup' function. ;) Pavel
Re: [9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
another way to implement these kinds of timeouts is alarm(), see sleep(2). -- cinap
Re: [9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
another way to implement these kinds of timeouts is alarm(), see sleep(2). Yes, I know. But it was just a simplified example to explain my real need: - 'receiver' process - another 'sender' process, which should have a possibility to close the TCP connection, and relase 'receiver' from read() call... Pavel
Re: [9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
ah, ok :) -- cinap
Re: [9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
OTOH, 'hangup' approach does not work in UDP. It means, read() is not finished... :( Pavel 2014-11-13 14:17 GMT+01:00 cinap_len...@felloff.net: ah, ok :) -- cinap
Re: [9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
interesting, that might be worth implementing. the alternative would be to send the reading process a note to interrupt the blocking syscall. the closer proc should just send the note and not close the fd. and the reader proc should close the fd once he's out of the reading loop. -- cinap
Re: [9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
interesting, that might be worth implementing. Maybe. the alternative would be to send the reading process a note to interrupt the blocking syscall. Actually, it my 'plan B'... ;) the closer proc should just send the note and not close the fd. and the reader proc should close the fd once he's out of the reading loop. Exactly! Well, I would prefer a solution with 'hangup', it seems cleaner to me... ...but since it is not implemented in UDP driver, I will implement the note based solution. Pavel Pavel
Re: [9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
the changes to implement udp hangup are trivial tho:
diff -r 51564dc1adae sys/src/9/ip/udp.c
--- a/sys/src/9/ip/udp.cThu Nov 13 10:23:53 2014 +0100
+++ b/sys/src/9/ip/udp.cThu Nov 13 15:42:24 2014 +0100
@@ -518,6 +518,11 @@
ucb = (Udpcb*)c-ptcl;
if(n == 1){
+ if(strcmp(f[0], hangup) == 0){
+ qhangup(c-rq, nil);
+ qhangup(c-wq, nil);
+ return nil;
+ }
if(strcmp(f[0], headers) == 0){
ucb-headers = 7; /* new headers format */
return nil;
--
cinap
Re: [9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
the changes to implement udp hangup are trivial tho:
diff -r 51564dc1adae sys/src/9/ip/udp.c
--- a/sys/src/9/ip/udp.cThu Nov 13 10:23:53 2014 +0100
+++ b/sys/src/9/ip/udp.cThu Nov 13 15:42:24 2014 +0100
@@ -518,6 +518,11 @@
ucb = (Udpcb*)c-ptcl;
if(n == 1){
+ if(strcmp(f[0], hangup) == 0){
+ qhangup(c-rq, nil);
+ qhangup(c-wq, nil);
+ return nil;
+ }
I see.
Going to try.
Pavel
Re: [9fans] Doesn't 'close' call finish pending 'read' on the same 'fd'?
+ if(strcmp(f[0], hangup) == 0){
+ qhangup(c-rq, nil);
+ qhangup(c-wq, nil);
+ return nil;
+ }
You patch works as expected. ;)
Thanks.
Pavel
[9fans] 9vx/Go/Yosemite questions
i succeeded in compiling a recent 9vx (from 0intro's repo on bitbucket) on linux, but not on osx. - is anyone working on porting this version to Yosemite? - in order to run go built for plan9/386 on 9vx, presumably go should be built without support for SSE2. is there a way to avoid this? Thanks, -Skip
Re: [9fans] 9vx/Go/Yosemite questions
On Nov 13, 2014 2:25 PM, Skip Tavakkolian skip.tavakkol...@gmail.com wrote: - in order to run go built for plan9/386 on 9vx, presumably go should be built without support for SSE2. is there a way to avoid this? set GO386 to 387 before running all.rc
[9fans] can't install 9front kernels
I recently updated my 9front and recompiled everything, including kernels and 9bootfat. After installing the new 9bootfat and kernels to /n/9fat, the system fails to boot. The computer (Thinkpad X220) just reboots after 9bootfat. If I replace the new 9pcf with the old version (the one that came with the installer some months ago), it works again (with the new 9bootfat), so something about the kernel must be wrong. I have the same problem with both the 9pcf and the 9pc64 kernels. I think I might have to change my configuration files, but I'm not sure how, or if that is even the problem. I haven't touched them so far. Fritz
Re: [9fans] can't install 9front kernels
Try removing the old 9bootfat before copying the new one into place. sl
Re: [9fans] can't install 9front kernels
can you provide that crashing kernel binary? -- cinap
Re: [9fans] can't install 9front kernels
I did that, just as it says in the FQA. I also did the chmod +al, and the 9bootfat seems to be ok, because it works when I combine the new 9bootfat and the old 9pcf. @cinap: should I send the binary directly to you? Am 13.11.2014 um 21:33 schrieb s...@9front.org: Try removing the old 9bootfat before copying the new one into place. sl
Re: [9fans] can't install 9front kernels
also, your plan9.ini contents would be nice to have. in case this is a regression instead of a corrupt kernel binary, it would help narrowing it down. -- cinap
Re: [9fans] can't install 9front kernels
yeah, sounds good. -- cinap
Re: [9fans] can't install 9front kernels
ok, i got your kernel images. and they are corrupt. they'r like 11MB in size (normal kernel, even with iwl blobs is like 6MB, 8MB is max) so they wont boot. my guess is that you have droped something into /lib/firmware or the bootfs that get embedded into the kernel image. verify that theres nothing under /lib/firmware, then mk clean and mk again would be my advice. -- cinap
Re: [9fans] can't install 9front kernels
/lib/firmware was indeed the problem. I have my wifi firmware there (and I need it there to use wifi), but when I installed it, I just extracted all the iwl firmware files there, not just the necessary one for my card. I deleted all files except for the needed one and it now works. Thanks a lot! Fritz Am 13.11.2014 um 23:21 schrieb cinap_len...@felloff.net: ok, i got your kernel images. and they are corrupt. they'r like 11MB in size (normal kernel, even with iwl blobs is like 6MB, 8MB is max) so they wont boot. my guess is that you have droped something into /lib/firmware or the bootfs that get embedded into the kernel image. verify that theres nothing under /lib/firmware, then mk clean and mk again would be my advice. -- cinap
