osdir.com
mailing list archive
Mozy Online Backup: 2GB Free. Automatic. Secure.

Subject: Re: ssax egg - msg#00060

List: lisp.scheme.chicken

Date: Prev Next Index Thread: Prev Next Index
Bruce Butterfield wrote:
After some discussion with other SSAX users a while back, a change to the input parsing code (core.scm in the chicken port) makes it thread-safe which is very important to my application. The default code uses a static buffer which as you might suspect doesn't work at all well in a multi-threaded environment. The updated code replaces input-parse:init-buffer as follows:

(define input-parse-buffer (make-parameter #f))

(define input-parse:init-buffer
(lambda ()
(or
(input-parse-buffer)
(let ((buffer (make-string 512)))
(input-parse-buffer buffer)
buffer))))

This code is slower than the default static buffer; perhaps someone could think of a clever runtime mechanism to use one mechanism over the other???



Well, not really clever, but you can check the list in the variable
##sys#features
for containing #:srfi-18. If that is the case, then you are either running in
the
interpreter, or in compiled code that uses the SRFI-18 features, and as such is
likely
to use threading. But that does of course not necessarily mean SSAX has to be
reentrant. Perhaps a runtime-switch? (I would prefer the default to be
thread-safe,
though).


cheers,
felix


Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Re: Chicken with CodeWarrior on Mac OSX

Todd R. Kueny, Sr. wrote: Has anyone gotten chicken to work on OSX CodeWarrior 9.2? I've been using gcc 3.1 on OSX and may have to switch. I darkly remember having Chicken once running under an ancient CW on Mac OS 9. It wasn't a problem at that time (besides working with that bloody SIOUX... ;-). As long as the compiler is solid (which I assume), I see no reason why it shouldn't work with CW. There are some __MWERKS macro uses in chicken.h and runtime.c, which might have to be re-evaluated, though. I (wrongly) assumed at that time that CW was a sure sign of an MacOS environment. cheers, felix

Next Message by Date: click to view message preview

[patch] write-string fails to check type of its params

The following (broken) code, when compiled, gives a strange error: > (declare (uses extras)) > (write-string "hey" (open-output-file "/tmp/foo")) I get: > Error: (make-string) size is negative: -536889320 Evidently, make-string is failing to check that its optional NUM parameter is a fixnum. Enclosed is a patch to have it perform the check (made against 1.45, but excluding the changes in extras.c from it; that means extras.c needs to be regenerated after the patch is applied). With the patch, the above code gives: > Error: (write-string) bad argument type - not a fixnum: #<output port > /tmp/foo> Took me a while to figure out what was going on. :) Thanks. Alejo. http://bachue.com/alejo ---=( Comunidad de Usuarios de Software Libre en Colombia )=--- ---=( http://bachue.com/colibri )=--=( colibri@xxxxxxxxxx )=--- patch Description: Text document signature.asc Description: Digital signature _______________________________________________ Chicken-users mailing list Chicken-users@xxxxxxxxxx http://mail.nongnu.org/mailman/listinfo/chicken-users

Previous Message by Thread: click to view message preview

Re: Chicken with CodeWarrior on Mac OSX

Todd R. Kueny, Sr. wrote: Has anyone gotten chicken to work on OSX CodeWarrior 9.2? I've been using gcc 3.1 on OSX and may have to switch. I darkly remember having Chicken once running under an ancient CW on Mac OS 9. It wasn't a problem at that time (besides working with that bloody SIOUX... ;-). As long as the compiler is solid (which I assume), I see no reason why it shouldn't work with CW. There are some __MWERKS macro uses in chicken.h and runtime.c, which might have to be re-evaluated, though. I (wrongly) assumed at that time that CW was a sure sign of an MacOS environment. cheers, felix

Next Message by Thread: click to view message preview

Re: ssax egg

Yes, I think that a library should be by default thread-safe unless marked otherwise in an obvious way. This has bitten me more than once since I write a lot of threaded code. felix wrote: Well, not really clever, but you can check the list in the variable ##sys#features for containing #:srfi-18. If that is the case, then you are either running in the interpreter, or in compiled code that uses the SRFI-18 features, and as such is likely to use threading. But that does of course not necessarily mean SSAX has to be reentrant. Perhaps a runtime-switch? (I would prefer the default to be thread-safe, though). cheers, felix -- Patriotism is your conviction that this country is superior to all others because you were born in it. George Bernard Shaw
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by