[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];

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()

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

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){ +

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){

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?

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

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

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

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