Re: reaping fd's and flushing buffers
On Mon, Jan 06, 2003 at 02:02:13PM -, Simon Marlow wrote: ... actually I've just looked at the code and it looks wrong, aargh! The finalizer is attached to the wrong side. If you have a source tree handy, try changing the following line in libraries/base/GHC/Handle.hs: addMVarFinalizer read_side (handleFinalizer read_side) to addMVarFinalizer write_side (handleFinalizer write_side) On Mon, Jan 06, 2003 at 06:13:27AM -0800, William Lee Irwin III wrote: Thanks, I've started brewing up a tree and I'll take that for a spin when it's done cooking. ouch! jadetex needs an upgrade (ghc debian maintainer?). But OTOH this does solve my problem. Thanks, Bill ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
jadetex (was: Re: reaping fd's and flushing buffers)
On Thu, Jan 09, 2003 at 02:37:03AM -0800, William Lee Irwin III wrote: On Mon, Jan 06, 2003 at 06:13:27AM -0800, William Lee Irwin III wrote: Thanks, I've started brewing up a tree and I'll take that for a spin when it's done cooking. ouch! jadetex needs an upgrade (ghc debian maintainer?). Probably related to this bug: http://bugs.debian.org/171985 ? (also includes hint for workaround) Cheers, Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: reaping fd's and flushing buffers
Sure enough, after I say that all my fd reaping issues are solved at the Haskell level, I've been bitten by issues that look like the RTS doing things behind my back wrt. reaping fd's etc. etc. Basically, while I used socketToHandle the fd's got closed prematurely, and once I eliminated all uses of it, the socket fd's appeared to leak despite attempts to explicitly close them. Also, there were some very strange goings-on with respect to attempts to flush buffers after the fd's they were being flushed to were closed. So, what are the semantics here? I wouldn't rule out a bug here. Sockets are actually implemented as two independent handles internally, one each for the read side and write side so that each side gets a separate buffer and duplex reading/writing from different threads is supported. The programmer still just sees a single Handle. The tricky bit is knowing when the socket can be closed: both sides have to be unreferenced by the program. We handle this by having the read side point to the write side, and then place the finalizer on the write side. The finalizer should then only run when both sides are unreferenced (of course, it's always better to do the closing explicitly if you can). ... actually I've just looked at the code and it looks wrong, aargh! The finalizer is attached to the wrong side. If you have a source tree handy, try changing the following line in libraries/base/GHC/Handle.hs: addMVarFinalizer read_side (handleFinalizer read_side) to addMVarFinalizer write_side (handleFinalizer write_side) Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: reaping fd's and flushing buffers
On Mon, Jan 06, 2003 at 02:02:13PM -, Simon Marlow wrote: ... actually I've just looked at the code and it looks wrong, aargh! The finalizer is attached to the wrong side. If you have a source tree handy, try changing the following line in libraries/base/GHC/Handle.hs: addMVarFinalizer read_side (handleFinalizer read_side) to addMVarFinalizer write_side (handleFinalizer write_side) Thanks, I've started brewing up a tree and I'll take that for a spin when it's done cooking. Thanks, Bill ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: reaping fd's and flushing buffers
perhaps this is related to these errors i get after my program runs for a while (about 2 days): I am guessing the no such protocol entry is because it cant open the /etc/protocols file due to a lack of fds. it is almost as if file descriptors are not being closed and leaking over time... ConnectionError ugcs.caltech.edu gale.ugcs.caltech.edu ugcs.caltech.edu.gale.org. (retrying in 5.0s): does not exist Action: getProtocolByName Reason: no such protocol entry ConnectionError ugcs.caltech.edu gale.ugcs.caltech.edu ugcs.caltech.edu.gale.org. (retrying in 5.0s): does not exist Action: getProtocolByName Reason: no such protocol entry ConnectionError ugcs.caltech.edu gale.ugcs.caltech.edu ugcs.caltech.edu.gale.org. (retrying in 5.0s): does not exist Action: getProtocolByName Reason: no such protocol entry ConnectionError ugcs.caltech.edu gale.ugcs.caltech.edu ugcs.caltech.edu.gale.org. (retrying in 5.0s): does not exist Action: getProtocolByName Reason: no such protocol entry ConnectionError ugcs.caltech.edu gale.ugcs.caltech.edu ugcs.caltech.edu.gale.org. (retrying in 5.0s): does not exist Action: getProtocolByName Reason: no such protocol entry ConnectionError ugcs.caltech.edu gale.ugcs.caltech.edu ugcs.caltech.edu.gale.org. (retrying in 5.0s): does not exist Action: getProtocolByName Reason: no such protocol entry attempt ExceptionCaught resource exhausted Action: openFile Reason: Too many open files File: /home/john/.gale/ginsu.pufflog.momenergy.repetae.net.4925.1041460077.1299 On Thu, Jan 02, 2003 at 11:15:28PM -0800, William Lee Irwin III wrote: Sure enough, after I say that all my fd reaping issues are solved at the Haskell level, I've been bitten by issues that look like the RTS doing things behind my back wrt. reaping fd's etc. etc. Basically, while I used socketToHandle the fd's got closed prematurely, and once I eliminated all uses of it, the socket fd's appeared to leak despite attempts to explicitly close them. Also, there were some very strange goings-on with respect to attempts to flush buffers after the fd's they were being flushed to were closed. So, what are the semantics here? Bill ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: reaping fd's and flushing buffers
On Fri, Jan 03, 2003 at 03:06:48AM -0800, John Meacham wrote: perhaps this is related to these errors i get after my program runs for a while (about 2 days): I am guessing the no such protocol entry is because it cant open the /etc/protocols file due to a lack of fds. it is almost as if file descriptors are not being closed and leaking over time... I removed the getProtocolByName path by using a raw integer port number and the error(s) still occurred. By listing /proc/$PID/fd I determined that they were sockets (which are listed in a special format). That investigation was prompted by strace(1)'s results, which indicated that the error returned was -EMFILE from socket(2). Bill ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
reaping fd's and flushing buffers
Sure enough, after I say that all my fd reaping issues are solved at the Haskell level, I've been bitten by issues that look like the RTS doing things behind my back wrt. reaping fd's etc. etc. Basically, while I used socketToHandle the fd's got closed prematurely, and once I eliminated all uses of it, the socket fd's appeared to leak despite attempts to explicitly close them. Also, there were some very strange goings-on with respect to attempts to flush buffers after the fd's they were being flushed to were closed. So, what are the semantics here? Bill ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
