Hi.
14.08.2012 06:23, Bart Oldeman ?????:
> it looks good to me, if it works well and is the cleanest solution by
> all means go for it;
Well, whether its cleanest is not me to judge, but
at least it is small. And it works well, yes, but it appears
to be easily breakable by the assumptions in int.c code,
so I had to do an extensive cleanups there to get something
stable. So, this is a bit below my initial expectation, and
because of that, I'd like the input from others.
But, after all, it seems to work right, and whoever changes
int.c, should just be aware about the simple limitations it puts.
(like, eg, do not assume that cs:ip points to an "int" instruction,
or not to call the DOS code with the non-local execution flow).
I think if we'd have a clean code initially, that would be a
no-brainer. But, since int.c is full of hacks, everything was
not all that simple. :) For example, I didn't expect that
do_int_from_hlt() calls the DOS code at all, but everything
was crashing till I found the nasty lfnhook and moved it
out of the thread. I hope this was the only place where
do_int_from_hlt() called the DOS code, but who knows...
> for now it's good to have it in the separate branch.
I am awaiting a confirmation that it fixes the bug with fossil.
After it is confirmed, it can keep staying in a separate branch
but no one will ever test it there, which is not very exciting.
> Maybe we should just call them coroutines, as that's what the C in PCL
> stands for, and as threads confuse me into thinking they run in parallel.
But the cooperative threading is exactly what can be implemented
on top of coroutines:
http://en.wikipedia.org/wiki/Coroutines
---
Coroutines are well-suited for implementing more familiar program
components such as cooperative tasks
<http://en.wikipedia.org/wiki/Cooperative_multitasking>
---
so I think the name is fine. There are 2 reasons why I
took it:
1. It is already familiar to dosemu developers
2. If libpcl already implements co-routines, then what
my code does? Oh, but it does cooperative threading!
Good term for marketing. :))
Not to confuse with the pre-emptive threading though.
> I experimented with sigsetjmp/siglongjmp for DPMI in 2006 (see git
> show 5504195d1),
How did you even do that?
Long jump back to the signal handler, or what?
> as essentially the DPMI code and DOSEMU code are two coroutines,
No, because you do not switch between them at arbitrary points.
You only have an entry point (signal handler), and a return
point (sigreturn() or direct switch trampoline). So it is more
like the kernel-user split. Dosemu is like a kernel that controls
the execution of DPMI "userspace", and you can't make them
a co-routines. Furthermore, if they be co-routines, I think you
won't be able to use longjmp(), because longjmp() is exactly
not good for co-routines. AFAIK longjmp() does stack unwinding...
but I can't find a good enough description to prove this. Anyway,
swapcontext() is what doing co-routines very well, but they all
are supposed to work only in a machine-independent environment.
If you are using machine-specific assembly to switch segments,
then I guess you can't expect any of those to work.
I am pretty sure "iret" is what supposed to be used to transfer
the control from kernel to user, and so, we should use that too
(which is what we do now, I think)
> but it is cleaner and saves an implicit sigprocmask call restoring scp
> and dropping out of the signal handler (aka calling sigreturn);
> setcontext() and friends don't support segment registers so can't jump
> into DPMI code, but a modified PCL may potentially help clarify here too.
I don't think it suits.
Ultimately, you'll end up switching to some asm trampoline
that will do iret, or you'll switch back to the signal handler,
but that's too far from the coroutines idiom IMHO.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dosemu-devel mailing list
Dosemu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dosemu-devel
