search for: reentranc

...in the current odesolve package) to make as few changes as possible to the Fortran 77 code. However, recently someone wanted to make nested calls to lsoda, which will not work, because Fortran is not generally reentrant. I understand I can use f2c to convert the codes to C, which would then gain reentrancy, and that there are parts of R which were translated from Fortran to C for just this reason (at least, I read that in an earlier R-help message). My questions to this group are: 1) Will this indeed automatically make the solvers reentrant? 2) How much do I need to worry about changed numerical b...

...ization to tell the host we don't need callbacks now. As it is not reliable, the debug check is overzealous: it can happen on two CPUs at the same time. Document this. Even if it were reliable, the virtio_net driver doesn't disable callbacks on transmit so the START_USE/END_USE debugging reentrance protection can be easily tripped even on UP. Thanks to Balaji Rao for the bug report and testing. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> CC: Balaji Rao <balajirrao at gmail.com> diff -r 0b3e64be7696 drivers/virtio/virtio_ring.c --- a/drivers/virtio/virtio_ring.c Mon...

...ization to tell the host we don't need callbacks now. As it is not reliable, the debug check is overzealous: it can happen on two CPUs at the same time. Document this. Even if it were reliable, the virtio_net driver doesn't disable callbacks on transmit so the START_USE/END_USE debugging reentrance protection can be easily tripped even on UP. Thanks to Balaji Rao for the bug report and testing. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> CC: Balaji Rao <balajirrao at gmail.com> diff -r 0b3e64be7696 drivers/virtio/virtio_ring.c --- a/drivers/virtio/virtio_ring.c Mon...

.... Are there any performance concerns from changing to a recursive lock? As for spinlocks themselves, as far as I can reason, recursive locks are safe to use, as are per-cpu spinlocks which are used exclusivly in the NMI handler or MCE handler (but not both), given the proviso that we have C level reentrance protection for do_{nmi,mce}(). For the {rd,wr}msr()s, we can assume that the Xen code is good and is not going to fault on access to the MSR, but we certainly cant guarantee this. As a result, I do not think it is practical or indeed sensible to remove all possibility of faults from the NMI pat...

Thanks for the tip, Brian. I did have a version that does everything in memory, but only had enough memory to get six threads going. (Although my system has 16GB, I have not taken the time to create 64-bit libraries for wxWidgets, TagLib, libFLAC, etc.) Based on the direction you are pointing me in, I assume that encoding from within the decoder is not permitted. I really like your idea of the

> How each target handles the code generation > differences will be the interesting part. Why not use a target specific calling convention? An interrupt is like a normal function call, it only has a different calling convention.

...would start as soon as a thread opens up. > Based on the direction you are pointing me in, I assume that > encoding from > within the decoder is not permitted. I have no idea. My assumption before your email would have been that the individual encoder/decoder handles would allow reentrancy, but perhaps there are pieces of libFLAC that are not reentrant even when working on separate encoder/decoder objects. The only way to know for sure is if Josh Coalson pipes up, or someone takes the time to look at the source for a thorough code review. There's a possibility that y...

I'm trying to use a Tk widget to show some progress & intermediate results in a long-running R calculation. Does anybody know how (or whether) I can force a window redraw without waiting for the idle loop? Currently, refreshes only seem to happen when we return to the R toplevel read-eval-print loop. Thanks, Mark <><

...ch below is a hack and cannot be directly applied due to other changes in my tree, but if someone would like to tackle this for 4.x I've provided you with a good start. The problem doesn't appear to be an issue in -current with the PROC lock held, though I am unsure if lock reentrancy is possible when a vm_fault is taken. -Matt Index: kern/kern_exit.c =================================================================== RCS file: /cvs/src/sys/kern/kern_exit.c,v retrieving revision 1.12 diff -u -r1.12 kern_exit.c --- kern/kern_exit.c 30 Jun 2003 19:50:31 -0000 1.12 ++...

I've got a song that causes the vorbis plugin for xmms to crash while reading the vorbis equivilent of id3 tags. What is the proceedure for reporting bugs like this. Do I mail the bug into this mailing list and then serve the song off of a FTP server? -ben --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this

...imple-8.swf.trace | 12 ++++ test/trace/unloadmovie-simple.as | 16 +++++ 22 files changed, 205 insertions(+), 37 deletions(-) New commits: commit 1453a43c36678b07a4c585e1173a0d4b78bc8e52 Author: Benjamin Otte <otte at gnome.org> Date: Fri Nov 9 17:22:55 2007 +0100 handle reentrancy correctly fixes mysterious segfaults on AMD64 diff --git a/libswfdec/swfdec_loader.c b/libswfdec/swfdec_loader.c index 04c21a0..618b9d7 100644 --- a/libswfdec/swfdec_loader.c +++ b/libswfdec/swfdec_loader.c @@ -210,9 +210,10 @@ swfdec_loader_init (SwfdecLoader *loader) static void swfd...

Hi I am trying to use nlm with an additional call to nlm within the function but after the first pass, the parameters to the outer call are being passed to the inner call. The inner call is a very trivial problem. ie: test.outer<-function(param.outer){ slope<-nlm(test.inner,param.inner) ... loglikelihood<-sum(...) return(-loglikelihood) } and nlm(test.outer,param.outer) on the

...is. On the route I learned C quite well and I discovered the power of scripting languages nad finally the S language. I wanted to write programs to perform routinely done exploratory data analysis, using gnuplot as the graphic driver. One of the my bigger concern has ever be memory management and reentrancy of my code, possibly avoiding using OS support (such as thread local storage on windows); I tried to allow for custom allocator in the library, supporting ANSI functions as a ready option ... I also have always used DOS (djgpp) and windows so I hated (and probably strongly dislike) autoconf and t...

...t;bar" to go ahead and see if you can find "bar" and immediately generated code for it. You can't do that in the FOOJIT model, because you won't know "bar" is undefined until you read the object back. However, in practice one needs to be careful about recursion and reentrancy, so you have to take care when trying to do things like this. The FOOJIT forces such tricks to go through a proper API (the FOO object) which I end up seeing as a feature, not a bug. -- And, a final word on API compatibility: As mentioned before, I have no *plan* to break any existing public int...

...9;t match - Rewrite win32_segv in terms of StringCcbPrintf to static storage and WriteFile(GetStdHandle(STD_ERROR_HANDLE), ...), which may be too much Attached is a crude first draft to see if the approach is viable. If it turns out to be a good idea, I can add the Rterm or thread ID checks, a reentrancy guard, declare and export a special struct win32_segvinfo from psignal.c, put all the crash reporting in win32_segv(), and move the VEH setup into psignal.c's signal(). (Just don't want to waste the effort if this proves ill-advised.) Without the patch: User at WIN-LGTSPJA3F1V MSYS /c/R/R...

I have spent quite some hours in the archives of this mailinglist and read a few threads mainly by Jeff Squyres and Monty about making oggenc multithreaded. Those threads all are dated around January 2001, quite a time ago. For my work experience period I have to implement a parallel (threaded) ogg encoder (If this is possible, of course.) If it can be done, the code will be given back to the

...ee > if you can find "bar" and immediately generated code for it. You can't > do that in the FOOJIT model, because you won't know "bar" is undefined > until you read the object back. > > However, in practice one needs to be careful about recursion and > reentrancy, so you have to take care when trying to do things like > this. The FOOJIT forces such tricks to go through a proper API (the > FOO object) which I end up seeing as a feature, not a bug. > -- > > And, a final word on API compatibility: > > As mentioned before, I have no *plan*...

...ee > if you can find "bar" and immediately generated code for it. You can't > do that in the FOOJIT model, because you won't know "bar" is undefined > until you read the object back. > > However, in practice one needs to be careful about recursion and > reentrancy, so you have to take care when trying to do things like > this. The FOOJIT forces such tricks to go through a proper API (the > FOO object) which I end up seeing as a feature, not a bug. > -- > > And, a final word on API compatibility: > > As mentioned before, I have no *plan*...

...quot;bar" and immediately generated code for it. > > You can't do that in the FOOJIT model, because you won't know "bar" > > is undefined until you read the object back. > > > > However, in practice one needs to be careful about recursion and > > reentrancy, so you have to take care when trying to do things like > > this. The FOOJIT forces such tricks to go through a proper API (the > > FOO object) which I end up seeing as a feature, not a bug. > > -- > > > > And, a final word on API compatibility: > > > > As...

...t;bar" and immediately generated code for it. You can't > > do that in the FOOJIT model, because you won't know "bar" is undefined > > until you read the object back. > > > > However, in practice one needs to be careful about recursion and > > reentrancy, so you have to take care when trying to do things like > > this. The FOOJIT forces such tricks to go through a proper API (the > > FOO object) which I end up seeing as a feature, not a bug. > > -- > > > > And, a final word on API compatibility: > > > &gt...