Re: [boost] Persistency library

Message: 10 Date: Sun, 25 Sep 2011 22:53:12 +0200 From: Oliver Kowalke <oliver.kowalke@gmx.de> To: boost@lists.boost.org Subject: Re: [boost] Persistency library Message-ID: <4E7F94B8.7030706@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I assume resuming from a checkpoint would also require to restore the registers, flags, stack (pointer), instruction pointer etc. - I'd like to know if your lib supports only intel or some other architectures too.
Oliver
Your assumption is correct. However, the actual implementation is done via getcontext()/setcontext(), so it is not hard-wired to a specific hardware architecture. We use assembly only in one case, and that is to avoid a glibc issue. PID is being cached in user-space and therefore isn't correct after restore, and glibc does not provide a simple way to invalidate this. Right now, the library has only been validated on x86-64, but I can of course validate it on other architectures (given the right hardware :)). Yair --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

I assume resuming from a checkpoint would also require to restore the registers, flags, stack (pointer), instruction pointer etc. - I'd like to know if your lib supports only intel or some other architectures too.
Oliver
Your assumption is correct. However, the actual implementation is done via getcontext()/setcontext(), so it is not hard-wired to a specific hardware architecture.
You know that ucontext-stuff (getcontext()/setcontext()/swapcontext()/makecontext()) is deprecated by POSIX 2003 and removed by POSIX 2008? For instance glibc doesn't implement those functionality on ARM. I don't know your implementation but on x86_64 the makecontext() function of glibc can not handle pointers as arguments (var-args for makecontext()). comment from makecontext.c (glibc-2.14): 'This implementation currently only handles integer arguments.' If you want to pass a pointer to the context-function via makecontext() you get a truncated address. Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

I assume resuming from a checkpoint would also require to restore the registers, flags, stack (pointer), instruction pointer etc. - I'd like to know if your lib supports only intel or some other architectures too.
Oliver
Your assumption is correct. However, the actual implementation is done via getcontext()/setcontext(), so it is not hard-wired to a specific hardware architecture.
You know that ucontext-stuff (getcontext()/setcontext()/swapcontext()/makecontext()) is deprecated by POSIX 2003 and removed by POSIX 2008? For instance glibc doesn't implement those functionality on ARM.
I don't know your implementation but on x86_64 the makecontext() function of glibc can not handle pointers as arguments (var-args for makecontext()). comment from makecontext.c (glibc-2.14): 'This implementation currently only handles integer arguments.' If you want to pass a pointer to the context-function via makecontext() you get a truncated address.
Oliver
I was unaware of this. My implementation does not rely on varags in makecontext(). Practically, it is possible to achieve the same flexibility by using setjmp()/longjmp() with minor effort. I believe this is common enough and supported on all platforms. Yair --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

I was unaware of this. My implementation does not rely on varags in makecontext().
ok - so your code requires a context-function of signature 'void f(void)'
Practically, it is possible to achieve the same flexibility by using setjmp()/longjmp() with minor effort.
Are you aware of the C99 standard which defines setjmp()/longjmp() to provide non-local jumps but does not require that longjmp() preserves the current stack frame, e. g. jumping into a function which was exited via a call to longjmp() is undefined? Oliver -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Practically, it is possible to achieve the same flexibility by using setjmp()/longjmp() with minor effort.
Are you aware of the C99 standard which defines setjmp()/longjmp() to provide non-local jumps but does not require that longjmp() preserves the current stack frame, e. g. jumping into a function which was exited via a call to > longjmp() is undefined?
Yes. The implementation I'm suggesting jumps into a function that hasn't exited yet. In short, we dump a memory image of the process including the stack and the jump buffer. The jump back is done into one of the predecessors of the image dump function, so the function has not exited yet. The relevant local variables are marked as volatile and are therefore clearly defined. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

Yes. The implementation I'm suggesting jumps into a function that hasn't exited yet. In short, we dump a memory image of the process including the stack and the jump buffer. The jump back is done into one of the predecessors of the image dump function, so the function has not exited yet.
The relevant local variables are marked as volatile and are therefore clearly defined.
boost.context implements the functionality of ucontext_t (using assembler for several archtiectures). I'm preparing the lib for the next mini-review. Maybe it could fit your requirements too. Oliver
participants (2)
-
Lifshitz, Yair
-
Oliver Kowalke