search for: reentrant

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, i build mysql (currently v5.0.22) on OSX 10.4.7 w/ threading enabled. i.e., i build the reentrant libs: libmysqlclient_r.dylib rather than the 'usual': libmysqlclient.dylib currently, to make Dovecot 'play nice' and recognize the reentrant libs, I: perl -pi -e 's/AC_CHECK_LIB\(mysqlclient,/AC_CHECK_LIB\(mysqlclient_r,/g' configure.in perl -pi -e 's/mysql_...

...ODEPACK. These are much-used and reliable Fortran codes, and I plan (as I did for lsoda 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 automatica...

...o. On 10/5/2014 8:07 PM, Michael S. Tsirkin wrote: > config_mutex served two purposes: prevent multiple concurrent config > change handlers, and synchronize access to config_enable flag. > Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1 > workqueue: make all workqueues non-reentrant > all workqueues are non-reentrant, and config_enable > is now gone. > Get rid of the unnecessary lock. > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/net/virtio_net.c | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) > diff -...

...o. On 10/5/2014 8:07 PM, Michael S. Tsirkin wrote: > config_mutex served two purposes: prevent multiple concurrent config > change handlers, and synchronize access to config_enable flag. > Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1 > workqueue: make all workqueues non-reentrant > all workqueues are non-reentrant, and config_enable > is now gone. > Get rid of the unnecessary lock. > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/net/virtio_net.c | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) > diff -...

...l S. Tsirkin wrote: >>> config_mutex served two purposes: prevent multiple concurrent config >>> change handlers, and synchronize access to config_enable flag. >>> Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1 >>> workqueue: make all workqueues non-reentrant >>> all workqueues are non-reentrant, and config_enable >>> is now gone. >>> Get rid of the unnecessary lock. >>> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> >>> --- >>> drivers/net/virtio_net.c | 7 +------ >>> 1 f...

...l S. Tsirkin wrote: >>> config_mutex served two purposes: prevent multiple concurrent config >>> change handlers, and synchronize access to config_enable flag. >>> Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1 >>> workqueue: make all workqueues non-reentrant >>> all workqueues are non-reentrant, and config_enable >>> is now gone. >>> Get rid of the unnecessary lock. >>> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> >>> --- >>> drivers/net/virtio_net.c | 7 +------ >>> 1 f...

Hi, I've seen that this commit never got MFC'd: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/realpath.c?rev=1.14&content-type=text/x-cvsweb-markup Would it be possible to do that or are there any objections out there ? Martin Martin Blapp, <mb@imp.ch> <mbr@FreeBSD.org> ------------------------------------------------------------------ ImproWare AG, UNIXSP

Hello, While working on a fix for the rare-but-possible problem of reentrant NMIs and MCEs, I have discovered that it is sadly possible to generate fake NMIs and MCEs which will run the relevant handlers on the relevant stacks, without invoking any of the other CPU logic for these special interrupts. A fake NMI can be generated by a processor in PIC mode as opposed to Virt...

...sage of LLVM? Should LLVM provide a locking mechanism for this or should there be a way to make the getenv() calls optional in the places there are used (like here in MCContext). Regarding the thread safety, this is what the open group says about getenv(): "The getenv() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe." http://pubs.opengroup.org/onlinepubs/009696799/functions/getenv.html -- Regards, Dirkjan Bussink

I don't know if __thread is well-supported enough on compilers to use in LLVM core code. LLVM has its own support class: ThreadLocal http://llvm.org/doxygen/classllvm_1_1sys_1_1ThreadLocal.html And if randr_r() is obsolete, I'm not sure we should be using it. What platforms have you tested this on? Is it available on Windows, Mac, BSDs? If not touching global state is important

If we're keeping the state locally now, perhaps we should store it in a per-thread variable. I know rand() isn't thread safe to begin with, but it seems like rand_r() can be since it should keep no external state. On Sat, Dec 1, 2012 at 11:17 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > Dear all, > > In our LLVM-based compiler pipeline a major part of code

...Tsirkin" <mst at redhat.com> wrote: > config_mutex served two purposes: prevent multiple concurrent config > change handlers, and synchronize access to config_enable flag. > > Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1 > workqueue: make all workqueues non-reentrant > all workqueues are non-reentrant, and config_enable > is now gone. > > Get rid of the unnecessary lock. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/net/virtio_net.c | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) >...

...Tsirkin" <mst at redhat.com> wrote: > config_mutex served two purposes: prevent multiple concurrent config > change handlers, and synchronize access to config_enable flag. > > Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1 > workqueue: make all workqueues non-reentrant > all workqueues are non-reentrant, and config_enable > is now gone. > > Get rid of the unnecessary lock. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/net/virtio_net.c | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) >...

Correcting my patch, reg. __thread stuff I'm not very familiar with. - D. 2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org> > Agreed, done. > > One thing I'm not sure about is this statement in docs: > > POSIX.1-2008 marks *rand_r*() as obsolete. > > - And... what is the replacement? > > > 2012/12/1 Justin Holewinski <justin.holewinski at

Dear all, In our LLVM-based compiler pipeline a major part of code generation is taken into application runtime. One side-effect of this organization is a need to be very careful about using code that might diverge application state. And we found that simple generation of temporary files over LLVM APIs introduces random noise into the program result. There reason is that LLVM's

Hi All, What is the current status of removing the global variables etc that is required to permit multi-threading R? I'm developing a web application tool for/using R, python (www.python.org), and Zope (www.zope.org), and it would be really convenient if I could use something like RPy to communicate with several concurrent R sessions, preferably within the same process space. -Greg

...e a > locking mechanism for this or should there be a way to make the getenv() > calls optional in the places there are used (like here in MCContext). > > Regarding the thread safety, this is what the open group says about > getenv(): > > "The getenv() function need not be reentrant. A function that is not > required to be reentrant is not required to be thread-safe." > > http://pubs.opengroup.org/onlinepubs/009696799/functions/getenv.html > > -- > Regards, > > Dirkjan Bussink > _______________________________________________ > LLVM Developer...

Agreed, done. One thing I'm not sure about is this statement in docs: POSIX.1-2008 marks *rand_r*() as obsolete. - And... what is the replacement? 2012/12/1 Justin Holewinski <justin.holewinski at gmail.com> > If we're keeping the state locally now, perhaps we should store it in a > per-thread variable. I know rand() isn't thread safe to begin with, but it > seems

Switch the lex/yacc parser into reentrant mode, to ease the handling of parsing-specific data; introduce a new parser_context struct for that, which is added as extra data to the parser. This should cause no behaviour changes in the parsing, just no more global variables used for getting data in/out the parser. --- builder/index-parse.y...

Asterisk has this error on compile: flex ast_expr2.fl "ast_expr2.fl", line 50: unrecognized %option: reentrant "ast_expr2.fl", line 51: unrecognized %option: bison-bridge "ast_expr2.fl", line 52: unrecognized %option: bison-locations make: *** [ast_expr2f.c] Error 1 2.6.12-1.1447_FC4smp #1 SMP bison (GNU Bison) 2.0 Written by Robert Corbett and Richard Stallman. Copyright (C) 2004 Fr...