reentrancy

I am reading a book called Linux System Programming . Quoting from this book: What about system calls and other library functions? What if your process is in the middle of writing to a file or allocating memory, and a signal handler writes to the same file or also invokes malloc()? Some functions are clearly not reentrant. If a program is in the middle of executing a nonreentrant function and a signal occurs and the signal handler then invokes that same nonreentrant function, chaos can ensue. But then it will follow: Guaranteed-Reentrant Functions Functions guaranteed to be safely reentrant

I would like to improve my understanding of the word reentrant. Is this function reentrant? function* foo() { yield 1; yield 2; } And this one? function foo() { return 1; } And this one? var x = 0; function foo() { return x++; } And this one? function foo() { setTimeout(foo, 1000); } A reentrent function is a function whose execution can be resumed: In computing, a computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete execution. In browser/node JavaScript,

For a multi-player programming game, I'm working on a background compilation server for Scala that supports compilation of multiple, independent source trees submitted by the players. I succeeded in running fast, sequential compilations without reloading the compiler by instantiating the Global compiler object via val compilerGlobal = new Global(settings, reporter) and then running individual compile jobs via val run = new compilerGlobal.Run run.compile(sourceFilePathList) I would now ideally like to parallelize the server (i.e. make multiple compilation runs concurrently), but still without

The Qt documentation states this about thread-safety and reentrancy : Note: Qt classes are only documented as thread-safe if they are intended to be used by multiple threads. If a function is not marked as thread-safe or reentrant, it should not be used from different threads. If a class is not marked as thread-safe or reentrant then a specific instance of that class should not be accessed from different threads. This seems to state that every function and class in Qt should be considered non-reentrant and non-thread-safe unless explicitly stated so. However, in the documentation of QRect and

I'm having trouble following the steps to make my bison/flex parser reentrant with a minimum amount of fuss. The problem appears to be in the lexer. Since everything parser is re-entrant, I can no longer assign yylval directly. Instead, according to the Flex manual , I have to call this function: void yyset_lval ( YYSTYPE * yylvalp , yyscan_t scanner ); But the problem is, YYSTYPE is an integral type. It isn't a dynamically allocated value, and it isn't an lvalue at all, so I can't pass a pointer to it! Am I missing something, and if not, how am I supposed to set yylvalue? I've never had this

If by some miracle a segfault occurs in our program, I want to catch the SIGSEGV and let the user (possibly a GUI client) know with a single return code that a serious problem has occurred. At the same time I would like to display information on the command line to show which signal was caught. Today our signal handler looks as follows: void catchSignal (int reason) { std :: cerr << "Caught a signal: " << reason << std::endl; exit (1); } I can hear the screams of horror with the above, as I have read from this thread that it is evil to call a non-reentrant function from a signal handler. Is

I'm learning how to use reentrant Bison and Flex together. I already got a simple calculator working without the reentrant capability. However when I activated the reentrant feature and made the necessary modifications, I couldn't get this to work. Here is the code: scanner.l %{ #include <stdio.h> #include "parser.tab.h" %} %option 8bit reentrant bison-bridge %option warn noyywrap nodefault %option header-file="lex.yy.h" DIGIT [0-9] %% "+" { return ADD; } "-" { return SUB; } "*" { return MUL; } "/" { return DIV; } {DIGIT}+ { *yylval = atof(yytext); return NUM; } \n { return EOL; } [ \t] { } .

According to APUE 2e Chapter 12.5: If a function is reentrant with respect to multiple threads, we say that it is thread-safe. This doesn't tell us, however, whether the function is reentrant with respect to signal handlers. We say that a function that is safe to be reentered from an asynchronous signal handler is async-signal safe. My questions are Q1: Is there a "general re-entrant" concept (which means re-entrantcy in all circumstances)? If there is, does general re-entrant equal to re-entrant with respect to both multi-thread and async-signal only? Or is there also a third condition that

At the moment, I have some functions which look like this: private bool inFunction1 = false; public void function1() { if (inFunction1) return; inFunction1 = true; // do stuff which might cause function1 to get called ... inFunction1 = false; } I'd like to be able to declare them like this: [NoReEntry] public void function1() { // do stuff which might cause function1 to get called ... } Is there an attribute I can add to a function to prevent reentry? If not, how would I go about making one? I've heard about AOP attributes that can be used to add code before and after function calls; would