Gambit-list Novembre 2006

gambit-list@iro.umontreal.ca

13 participants
20 discussions

Edge triggered I/O with libevent
by Adam Langley 04 Avr '13

04 Avr '13

Gambit uses the select call on POSIX systems to multiplex IO operations. This is fine for small numbers of file descriptors, but falls apart quickly with large numbers[1]. libevent[2] is a wrapper library around a number of modern IO multiplexing systems (epoll on Linux, kqueue on the BSDs as well as poll and select). Attached is a patch which converts Gambit to using edge triggered I/O with epoll and libevent. This also requires a patch (attached) of libevent since the standard distribution doesn't include edge triggering support and the upstream appears to be on holiday. (epoll is required because I don't have a BSD box on which to develop edge triggering support for kqueue) This patch (for Gambit) preprocesses away to nothing unless --enable-libevent is passed to the configure script. (Note that, since this patches the configure.ac script, you'll need to run autoconf to regenerate). I hope I've not broken anything, but at this stage I've only tested that the console and tcp ports work. This patch (in the future) should also allow people, who write programs which use socket calls directly, to integrate into the main event loop at some point. Testing is more than welcome and, if you find a form of IO which is broken, please email me. [1] http://monkey.org/~provos/libevent/libevent-benchmark2.jpg [2] http://monkey.org/~provos/libevent/ -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60

2 2

Re: [gambit-list] compiler bug?
by Marc Feeley 03 Sep '07

03 Sep '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25-Sep-06, at 3:48 PM, Sven.Hartrumpf(a)FernUni-Hagen.de wrote: > Hello Marc. > > I have a large program which behaves a little different > with gsc than any other Scheme I know of (bigloo, chicken, gauche): > Here is the problematic region: > > (let* ((orth (and (pair? word-info) > ;(not (eq? (caar word-info) 'words)) > (fs-value (car word-info) '(orth)))) > (orth-l (if orth (string-length orth) 0)) > (left-hyphen (and (> orth-l 2) > (char=? (string-ref orth 0) # > \-))) ; examples: \quw{Steuergesetzgebung und -verwaltung}, \quw > {auspringen und -setzen} > (right-hyphen (and (> orth-l 1) > (char=? (string-ref orth (- orth- > l 1)) #\-))) > (step (if left-hyphen > (and (not right-hyphen) > -1) > (and right-hyphen > 1)))) > > left-hyphen and right-hyphen are evaluated to #f for some binding - > this > is as expected. But step is bound to 1 which seems wrong to me. > Minimizing the problem might be hard for me, so I hope that you can > see > the problem already :-) > > Ciao > Sven Sven, you have just uncovered a nasty bug in the compiler. In beta 18 the transformation for the "and" form is too aggressive in the case where the second argument is a constant. As far as I can tell this bug was introduced just before beta 18 was released. Surprisingly in the 70Kloc in the Gambit runtime system and compiler this case does not occur. I have now fixed the bug and will release beta 19 shortly because this is a serious bug. Thanks! Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFGEqS//V9Zc2T/v4RAqTeAJ9asp7elGoK7yqa6MzmLFTRj6K8UwCfc3d4 5haROCNvlgMs1NREyZCgYIw= =bvLI -----END PGP SIGNATURE-----

2 1

Obscurities with FFI and possible bug
by Christian 30 Nov '06

30 Nov '06

Hello I am sometimes getting segfaults with this code: (c-declare " typedef int MPI_Comm; static MPI_Comm globalcomm=123; ") (c-define-type MPI_Comm "MPI_Comm") (define get-comm (c-lambda () MPI_Comm "___result_voidstar=&globalcomm;")) See below for a sequence of commands with which I can consistently get a segfault. Strangely, a test function looping over about the same sequence doesn't trigger it. Am I doing things right? I don't want to just (c-define-type MPI_Comm int), because that would breach encapsulation (I only found out that MPI_Comm (I'm binding PETSc) was an int by looking at the gcc -E output!). Do I understand right that I am supposed to give a pointer to the data? e.g. "___result_voidstar=&globalcomm;", not "___result_voidstar=globalcomm;"? That should probably be made clear in the documentation. I've also tried (c-define-type MPI_Comm (type "MPI_Comm")) at first. But probably I'm better of just doing this?: (c-define-type MPI_Comm (pointer "MPI_Comm")) Also: are (c-define-type MPI_Comm "MPI_Comm") and (c-define-type MPI_Comm (type "MPI_Comm")) really equivalent? I'm confused: - from reading the documentation, I thought that (type "MPI_Comm") will create a copy of the "MPI_Comm" object (how?, by applying memcpy to sizeof(MPI_Comm)?) and deallocate that again transparently upon destruction of the foreign object. - when seeing the ___release_rc calls under gdb (where the segfault happens), I thought that this is the release function. But looking at mem.c that rather looks like some management function for the scheme heap? - but seeing those #<foreign #2 0xB7FD630C> #<foreign #3 0xB7FD630C> I notice that they always carry the same address, so that would contradict the expectation of a new malloc'ed copy every time. BTW note that I'm still running the gambit beta 17. Thanks Christian. The test loop which does *not* segfault: ; (define (test n) ; (let lp ((i 0) ; (c #f)) ; (if (< i n) ; (lp (+ i 1) ; (get-comm))))) ; (time (test 1000000)) ; 496 ms real time ; 488 ms cpu time (488 user, 0 system) ; 28 collections accounting for 324 ms real time (316 user, 0 system) ; 36000000 bytes allocated ; no minor faults ; no major faults ;?? An example of a segfault (using chjmodule): (note: those 1's and 3's are just there to flush the old values from my repl value cache patched into gambit) > (use bug-MPI_Comm) loading "~/schemedevelopment/gambit/Loader/gambit-interpreter-env-bindings.o1" into namespace ""...done. import from "" to "gambit-interpreter-env#": 777 newly copied, 0 previously done. loading "~/schemedevelopment/gambit/Loader/gambit-interpreter-env.o1" into namespace "gambit-interpreter-env#"...done. import from "gambit-interpreter-env#" to "cj-env#": 785 newly copied, 0 previously done. import from "gambit-interpreter-env#" to "oleg-env#": 785 newly copied, 0 previously done. loading "~/schemedevelopment/gambit/mod/oleg-env.o1" into namespace "oleg-env#"...done. import from "oleg-env#" to "cj-env#": 3 newly copied, 0 previously done. loading "~/schemedevelopment/gambit/mod/cj-env.o13" into namespace "cj-env#"...done. import from "cj-env#" to "": 45 newly copied, 0 previously done. loading "./bug-MPI_Comm.o2" into namespace ""...done. import from "" to "": 0 newly copied, 0 previously done. > (get-comm) #<foreign #2 0xB7FD630C> > 1 1 > 1 1 > 1 1 > 1 1 > (##gc) > (##gc) > (##gc) > (##gc) > (get-comm) #<foreign #3 0xB7FD630C> > 3 3 > 3 3 > 3 3 > 3 3 > (##gc) > (##gc) > (##gc) > (get-comm) #<foreign #4 0xB7FD630C> > (get-comm) #<foreign #5 0xB7FD630C> > 3 3 > 3 3 > 3 3 > 3 3 > (##gc) > (##gc) > (##gc) > (##gc) > (##gc) > (get-comm) #<foreign #6 0xB7FD630C> > (get-comm) #<foreign #7 0xB7FD630C> > (get-comm) #<foreign #8 0xB7FD630C> > 3 3 > 3 3 > 3 3 > 3 3 > (##gc) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1214533504 (LWP 22116)] ___release_rc (ptr=0x0) at mem.c:630 630 next->prev = prev; and a backtrace from another one: > (##gc) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1214578560 (LWP 23687)] ___release_rc (ptr=0x0) at mem.c:630 630 next->prev = prev; (gdb) bt #0 ___release_rc (ptr=0x0) at mem.c:630 #1 0xb7fca829 in ___release_fn0 () from /home/chris/schemedevelopment/gambit/work/./bug-MPI_Comm.o2 #2 0xb7fcb30c in _ () from /home/chris/schemedevelopment/gambit/work/./bug-MPI_Comm.o2 #3 0xb7ed5e91 in ___lbl_tbl () from /usr/local/Gambit-C/lib/libgambc.so #4 0xb7fbc0e0 in __JCR_LIST__ () from /usr/local/Gambit-C/lib/libgambc.so #5 0xb7d3cb1b in ___release_foreign (obj=59) at c_intf.c:1173 #6 0xb7d3a6e5 in free_unmarked_still_objs () at mem.c:2332 #7 0xb7d3b667 in ___garbage_collect (nonmovable_words_needed=0) at mem.c:3652 #8 0xb7d5434a in ___H__20___kernel (___ps=0xb7fc0320) at _kernel.c:7542 #9 0xb7d3830d in ___call (nargs=0, proc=-1209180911, stack_marker=136566237) at setup.c:1784 #10 0xb7d3927e in ___setup (setup_params=0x0) at setup.c:2909 #11 0xb7d369c8 in ___main (linker=0) at main.c:557 #12 0xb7d414a9 in ___main_char (argc=6, argv=0x0, linker=0, script_line=0x0) at os_base.c:240 #13 0x0816207f in main ()

1 0

SLIB
by Nicholas Walton 28 Nov '06

28 Nov '06

Hi, Could anyone confirm the status of SLIB with Gambit 4? Are there work arounds for any known problems? Many Thanks NIck Walton

2 1

problem with serialization/deserialization of structures
by Alexey Voinov 27 Nov '06

27 Nov '06

Hello. A friend of mine recently discovered strange behavior in gambit interpreter: $ gsi Gambit Version 4.0 beta 20 > (define-structure foo x y) > (define a (make-foo 11 22)) > a #<foo #2 x: 11 y: 22> > (foo? a) #t > (define b (u8vector->object (object->u8vector a))) > b #<foo #3 x: 11 y: 22> > (foo? b) #f > (define c (u8vector->object (object->u8vector a))) > c #<foo #4 x: 11 y: 22> > (foo? c) #f > (##vector-ref a 0) #<type #5 foo> > (##vector-ref b 0) #<type #6 foo> > (##vector-ref c 0) #<type #7 foo> > Note, now we have three different types named foo, but can do anything useful only with one of them. -- Alexey Voinov

2 1

Expanding Macros
by Mark Smith 23 Nov '06

23 Nov '06

Hi guys, First time on the mailing list, or any mailing list for that matter. I have a very simple question about macros if someone would fill me in: how do I expand a macro like you can in Common Lisp or some other Scheme implementations? I've been using the pp function but it complains under some situations i.e. when my macro expands into a definition. Thanks in advance, Mark.

2 1

DS port successful!
by Andrew Lentvorski 20 Nov '06

20 Nov '06

Well, after much pain, the Gambit DS port seems to work. I can open a repl to port 7770 and do basic command line stuff. Is there somewhere I can put the repository for folks to play with? Or at least as an example for other embedded developers to pound on. I'm really concerned that I'm still above 2MB for the binary; I'd like to be around 1MB. My biggest gain came from switching to the thumb instruction set on the ARM9. I gained something like 500K out of what initially was a 2.9MB file. I really don't understand why. Thanks, -a

2 2

Displaying Exceptions: internal gambit function I can use?
by Jonathan Arkell 16 Nov '06

16 Nov '06

Hey guys, I'd like to re-use part of the Gambit exception handler, specifically the part that displays the details of the current exception. I'd also like to hook into the display routine to specialize the display of my own custom exceptions, but this is mostly secondary. Cheers Jonathan Arkell jonnay(a)jonnay.net

2 2

More DS porting issues
by Andrew Lentvorski 16 Nov '06

16 Nov '06

Okay, I have a repl and it's stable. That wasn't too bad. I can start web-repl.scm and get to a select statement. That was a pain. I had to do a pretty large refactor spanning quite a bit of the os_XX files. It has a lot of POSIX'ness wired into the assumption. And ... select() doesn't work in dswifi. Sigh. Any advice for how to fake a "select" with polling? What kind of repercussions are there going to be if I return from the select too early? Are there going to be implications if the select() for sockets if different from the select() for stderr/stdout? Thanks, -a

2 2

More inlining notes
by Bradley Lucier 13 Nov '06

13 Nov '06

Marc: You should inline abs. Basically, you should inline anything that you have a GVM macro for in gambit.h, but I can't seem to find a systematic way to test whether you do so. Is there a simple way to find out whether a given function will be inlined for either fixnum or flonum arguments? Brad

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Novembre 2006