I agree with Breed -- no understanding of what you all are talking about, but nonetheless I find it fascinating. Also, appreciate the efforts very much. Keep it up!
You are doing a big, great job keep time no one here are asking you have to hurry :) ... if some one do can make the port him self, and i think you are the only one who take this strong big huge job
After running it in os3/winuae/kcon shell and it exit from back to shell: tc_UserData are null.
After running it in os4 shell and it exit from back to shell: tc_UserData are value (not null).
After running it in morphos shell and it exit from back to shell: tc_UserData are null.
What mean that tc_UserData auto-cleans in their shell when exit from program running in shell happens, as well as it was like this on os3's kcon too (and i assume on default one too?). Now question is: as it shell, and it the same for os3 as for mos too, then should our os4 shell be fixed to do the same? I mean is there any specification or something which told what for example old os3.x shell do with it, should it worry about at all, or its all up to developer who use tc_UserData. As its clear now, that only os4 shell do not clean tc_UserData on exit, while os3 and mos ones are.
Anyway, its clear now that because of that, Odyssey's code make assumption that on every run tc_UserData are NULL, and we need save and restore tc_UserData on run/exit for os4 (Done), but maybe our shell need fixing too.
Edited by kas1e on 2014/3/3 6:07:25 Edited by kas1e on 2014/3/3 6:08:46
@joerg I also do better look on that MachineStackMarker.cpp, and all that morphos code in no use there, but not because of MORPHOS (as we should be in), but because its all in the ENABLE(JSC_MULTIPLE_THREADS), which is not enabled for my build, and i do not know if it enabled for mos build, but as code is here, seems should be..
I can try to enable pthreads and get rid of mos code in those JSC_MULTITHREADED parts. If all that stuff will make in end faster usage for us. But imho easy and better way its just ENABLE_JSC_MULTIPLE_THREADS=1 and adapt those parts in morphos blocks, as whole code for sure do not want to be mixed.
Btw, your old owb done with -DWTF_USE_PTHREADS=1 and -DENABLE_JSC_MULTIPLE_THREADS=1 or without ?
Edited by kas1e on 2014/3/3 8:55:08 Edited by kas1e on 2014/3/3 8:57:59 Edited by kas1e on 2014/3/3 9:02:42 Edited by kas1e on 2014/3/3 9:09:57
Anyway, its clear now that because of that, Odyssey's code make assumption that on every run tc_UserData are NULL, and we need save and restore tc_UserData on run/exit for os4 (Done), but maybe our shell need fixing too.
Interesting, although it may not be the shell, it could be the c library startup code.
PS (KCON is *not* a shell its a console, the shell is part of DOS and is what actually runs commands etc, the console is where it displays it's output etc)
Btw, your old owb done with -DWTF_USE_PTHREADS=1 and -DENABLE_JSC_MULTIPLE_THREADS=1 or without ?
Which of the old OWB versions, 1.21 or 2.20? The current version of OWB is build with WTF_USE_PTHREADS=1, HAVE_PTHREAD_RWLOCK=0, ENABLE_JSC_MULTIPLE_THREADS=0, ...
struct PPCRegFrame
{
u_int32_t StackGap[4]; /* StackFrame Gap..so a function working
* with the PPCRegFrame as the GPR1 doesn`t * overwrite any contents with a LR store at 4(1)
*/
u_int32_t Version; /* Version of the structure */
u_int32_t Type; /* Type of the regframe */
u_int32_t Flags; /* The filled up registers */
u_int32_t State; /* State of the Thread(only used for Get) */
I.e for first part we need to make aos4 typedef for PlatformThreadRegisters , for second part way to get thread registers and in end need a way to get the stack pointer for another thread.
Sure it can be all different , but whatever. Just even some prototype idea will be ok to start with, and then we can adapt it to working state.
Just when i build morphos version of 1.23, it was disabled by default and i have -DENABLE_JSC_MULTIPLE_THREADS=0 in morphos build as well. But as code is here, i curious if it works on morphos already and enabled ?
Maybe you can help with that MachineStackMarker stuff, i.e those 3 parts of code need os4 analog to make js threading works:
You don't need any changes if you enable WTF_USE_PTHREADS, except for removing the OS(MORPHOS) parts, and with pthreads.library 53.11 or newer you don't need to disable HAVE_PTHREAD_RWLOCK.
You could use AmigaOS specific code instead, but why? The MorphOS code makes no sense, unless it's a workaround for bugs in MorphOS, and it seems to be incomplete. For AmigaOS, and any AmigaOS compatible OS, you don't need PlatformThreadRegisters and can disable getPlatformThreadRegisters() and otherThreadStackPointer(), and use something like
suspendThread() should use IExec->SuspendTask(platformThread, 0) instead of Disable() which makes no sense at all (even for disabling multitasking completely instead of only stopping one task, which is wrong anyway, using IExec->Forbid() would have been enough) and resumeThread() IExec->RestartTask(platformThread, 0).
But since you always only post small, incomplete parts of the sources with which it's impossible to port it to AmigaOS you have to port it yourself if you don't want to use pthreads.
@kas1e Any memory allocated by malloc() is allocated by the C lbraries freed when the program exits. Memory allocated by AllocSysObjectTags() might not be freed unless FreeSysObject() is called before quitting the program. In fact, FreeSysObject() might not free the memory; it might just put it in a list for reuse for all we know. I think it's a non-issue.
This multiple threads part is implemented and enabled in morphos, just so that webkit synchronization and compilation are made easier, but it's actually not used at all in practice (this code is used by external jsc clients, and possibly by webkit2, but not webkit itself). It's also totally unrelated to javascript workers, for instance.
Regarding the code itself, while Forbid() might be enough, I definitely wouldn't recommend Suspend/RestartTask.
@xenic
Of course using malloc() is a non issue, if the underlying clib is properly done. In MorphOS, it internally uses a mempool and all the allocated memory is given back at exit.
On the other hand, i really wouldn't use directly AllocVec*/AllocMem* in WebKit, and especially JSCore, because it tends to leak a lot (due to remaining live js references/objects in allocated blocks), and as a consequence, the leaks wouldn't be recovered at all after program exit.
At least, if you really don't want to use malloc(), at least keep track of your allocation, or better, use a mempool.
Sorry for my impatience, but there are nothing to report since two days. Maybe you have surely other things to do or could this mean we will see a Beta release soon?
@younghippie All done, just waiting for new mui release, because:
1). new version of odyssey want new mui class for autoform filling (which is done and will be released in new version of mui). 2). in new version of mui fixed all bugs related to tabs, so i will set minimum req to that mui on startup as well, so no reports from old mui will be about crashes in tabs. 3). few bugs related to odyssey was fixed too in mui
But in terms of whole port all done (without fullscreen youtube of course, just a window, when it will be done it can be then released as update or with next version of odyssey or something).
In other words waiting for new mui release (when , dunno, but i assume pretty soon)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
