search for: fuhm

http://bugzilla.mindrot.org/show_bug.cgi?id=910 foomzilla at fuhm.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From foomzilla...

On Jan 4, 2010, at 4:35 AM, Chandler Carruth wrote: > Responding to the original email... > > On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: >> In working on an LLVM backend for SBCL (a lisp compiler), there are >> certain sequences of code that must be atomic with regards to async >> signals. > > Can you define exactly what 'atomic with regards to async signals' > this entails? Your des...

Responding to the original email... On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: > In working on an LLVM backend for SBCL (a lisp compiler), there are > certain sequences of code that must be atomic with regards to async > signals. Can you define exactly what 'atomic with regards to async signals' this entails? Your descriptions led me to think...

On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: > Hi, thanks everyone for all the comments. I think maybe I wasn't clear that > I *only* care about atomicity w.r.t. a signal handler interruption in the > same thread, *not* across threads. Therefore, many of the problems of > cross-CPU atomicity are not relevant. Th...

On Mon, Jan 4, 2010 at 8:43 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: >> Hi, thanks everyone for all the comments. I think maybe I wasn't clear that >> I *only* care about atomicity w.r.t. a signal handler interruption in the >> same thread, *not* across threads. Therefore, many of the problems of >> cross-CPU atomicity are...

http://bugzilla.mindrot.org/show_bug.cgi?id=454 ------- Additional Comments From foomzilla at fuhm.net 2004-12-17 06:01 ------- See also bug 910 for a patch. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

...Product: Portable OpenSSH Version: 3.4p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: foomzilla at fuhm.net I have two SSH servers running on the same machine. One is running on port 22 for standard logins; the other is running port 4005, and is not run by root. They both must have different host keys, as the sshd on port 4005 cannot (and should not) be able to read the host keys for the standard...

http://bugzilla.mindrot.org/show_bug.cgi?id=454 ------- Additional Comments From markus at openbsd.org 2002-12-10 20:14 ------- hm, i think about adding ManglePort=yes to the options. This option will create Hostkeyaliases on the fly if the port is != 22, and use 'foor.bar.com at portXXX' as an alias. ------- You are receiving this mail because: ------- You are the assignee for

On Mon, Jan 4, 2010 at 8:51 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Mon, Jan 4, 2010 at 8:43 PM, Chandler Carruth <chandlerc at google.com> wrote: >> On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: >>> Hi, thanks everyone for all the comments. I think maybe I wasn't clear that >>> I *only* care about atomicity w.r.t. a signal handler interruption in the >>> same thread, *not* across threads. Therefore, many of the problems of >>> cross-CP...

On Jan 5, 2010, at 1:09 AM, Chandler Carruth wrote: >>>>> Consider that 'memset' to zero is often codegened to a non- >>>>> temporal >>>>> store to memory. This exempts it from all ordering considerations Hm...off topic from my original email since I think this is only relevant for multithreaded code... But from what I can tell, an

In working on an LLVM backend for SBCL (a lisp compiler), there are certain sequences of code that must be atomic with regards to async signals. So, for example, on x86, a single SUB on a memory location should be used, not a load/sub/store sequence. LLVM's IR doesn't currently have any way to express this kind of constraint (...and really, that's essentially impossible since

http://bugzilla.mindrot.org/show_bug.cgi?id=910 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |foomzilla at fuhm.net ------- Additional Comments From djm at mindrot.org 2005-04-21 18:16 ------- *** Bug 454 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=910 mindrot at askneil.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mindrot at askneil.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the

The LLVMAddFunctionAttr and LLVMRemoveFunctionAttr are busted: they actually set the return value's attributes, not the function's attributes. There seems to be no C API for actually setting the function attributes. LLVMGetFunctionAttr, however, does correctly return the function attributes, not the return value's attributes. There is no C API for getting the return value