Re: buildFdSets: file descriptor out of range
Hello, I have a standalone (i.e. not integrated into the RTS yet) proof of concept working using kqueue. However, to be portable we still need to fall back to select on systems that don't support anything better. This implies that if you want to write portable code you still suffer from this limit. If portability is important, how about falling back to poll(), not epoll()? I've been unable to hack lately due to an injury but I'll be able to get back to it next week. Take care. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: buildFdSets: file descriptor out of range
2009/7/16 Kazu Yamamoto k...@iij.ad.jp Hello, I have a standalone (i.e. not integrated into the RTS yet) proof of concept working using kqueue. However, to be portable we still need to fall back to select on systems that don't support anything better. This implies that if you want to write portable code you still suffer from this limit. If portability is important, how about falling back to poll(), not epoll()? We could provide poll as a possible backend but I don't think it's available on Windows. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: buildFdSets: file descriptor out of range
On 16/07/2009 06:53, Kazu Yamamoto (山本和彦) wrote: Hello, Reduce this to 1024, otherwise the runtime will eventually find itself dealing with file descriptors beyond the select() limit mentioned above. Someone with more knowledge of the Haskell runtime will have to advise as to possible ways around it if you really need more than 1024 file descriptors. There's no easy workaround. We could have the IO library switch to using blocking read() calls for the out-of-range FDs to avoid the error from the IO manager, but that is likely to lead to a different problem: too many OS threads. Thank you for reply. I changed forkIO to forkOS. But I received the following error. ERRORCannot create OS thread. I don't think forkOS is going to help you here. The IO library is still using select(), all you're doing is making more OS threads. We could do blocking read() for a bound thread. That would make some sense, but we don't do it at the moment, and it does add an extra test to the code. I want to decrease the stack size of threads to increase the number of threads to be created. How can I do this? That's an OS issue, I'm not sure. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: buildFdSets: file descriptor out of range
On Jul 16, 2009, at 03:32 , Johan Tibell wrote: 2009/7/16 Kazu Yamamoto k...@iij.ad.jp I have a standalone (i.e. not integrated into the RTS yet) proof of concept working using kqueue. However, to be portable we still need to fall back to select on systems that don't support anything better. This implies that if you want to write portable code you still suffer from this limit. If portability is important, how about falling back to poll(), not epoll()? We could provide poll as a possible backend but I don't think it's available on Windows. http://plibc.sourceforge.net/ ? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC version 6.10.4
== The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 == The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.10.3, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.10.4/html/users_guide/release-6-10-4.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HPC gives spurious results if sources are compiled with -cpp
On Tue, Jul 14, 2009 at 09:08:46AM +, Dominic Steinitz wrote: ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 ghc.exe -fhpc -cpp --make CommonHPC.hs -o CommonHPC commonHPC hpc markup CommonHPC --fun-entry-count This gives no entry counts for fact in Common.hs. Thanks for the report; I've filed it here: http://hackage.haskell.org/trac/ghc/ticket/3376 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.4
The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 How to get it http://www.haskell.org/ghc/ I have a few comments about the Distribution Packages page that is linked from there: http://www.haskell.org/ghc/distribution_packages.html Debian: Remove the line Newer packages may be available in Haskell Unsafe. That stuff is very, very old. Mac OS X: Paragraph beginning Contrary to the recommendation at the top of this page... rather than using the alternatives below. It makes no sense. It appears to be referring to an older version of the page. Both 10.3 (Panther) and 10.4 (Tiger) are supported. should be changed to 10.4 (Tiger) and 10.5 (Leopard). The paragraph about the ghc-devel port should be removed, I think. The port still exists, but it doesn't seem to be actively supported since 6.7. Anyone who wants to use GHC HEAD will probably just build current HEAD manually. (Greg - is this correct?) Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
