Hacker News new | past | comments | ask | show | jobs | submit login

you seem to be discussing what does or doesn't support multiple threads, but what we were talking about is what does or doesn't support multiple simultaneously existing hash tables, which hcreate() doesn't. i've edited my comment upthread to clarify

(it's also true, as kimixa points out, that a single-threaded process with signal handlers isn't really single-threaded, but i don't think that's really the important consideration in this context)

for what it's worth, it's not very difficult to use alarm() to invoke a context-switching subroutine to get preemptive user-space multithreading on unix without any kernel support. in theory you have to write the context-switching subroutine in assembly language, which isn't difficult at all; here's one i wrote in arm assembly for the arm eabi, for cooperative multithreading:

            .thumb_func
            .globl einyield
    einyield:
            push {r0, r4-r11, lr}   @ save all callee-saved regs plus r0
            ldr r0, =current_task_pointer
            ldr r1, [r0]
            str sp, [r1]            @ save stack pointer in current eintask
            ldr r1, [r1, #4]        @ load pointer to next eintask
            str r1, [r0]
            ldr sp, [r1]            @ switch to next eintask's stack
            pop {r0, r4-r11, pc}    @ return into einyielded context there
(from http://canonical.org/~kragen/sw/dev3/einkornix.S)

but in practice you can usually just use longjmp()

preemptive multithreading requires you to save all the registers, not just the callee-saved registers, but so does signal handling, so you can usually just use the signal-handling machinery and use the above code (or its equivalent on your vax or 68000 or whatever) to context-switch between signal-handler stack frames




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: