Subject: Re: [sablevm-jchevm] Windows port - msg#00021

List: java.vm.sablevm.devel

Date: Prev Next Index Thread: Prev Next Index

James Mansion wrote:

In any case, I think that the Windows port should rely on
the pthread library written for Windows.

I don't think that's a very good idea:

1) it has the wrong license (I think - has pthread-Win32 changed?)

2) it uses the relatively high-level Win32 facilities to bodge
together an emulation of rather lower-level facilities. If you
then use that to implement a higher-level abstraction again
for Java with recursive locks and signals, then its likely to
be less than optimal. Better, then, to look at a focussed
abstraction and implement for both threading models as
efficiently as you can. Bear in mind that the Win32
threading has the weight of a rather large number of host
systems behind it.

You might be better off with ZThreads if you really don't
want to do a direct port - or (better) look at the high-level
implementations you want, and offer them to APR (or APRUtil)
based on the low-level code in APR.

James

(Also - it would be *really* handy to have a source tree
thats more or less self-contained and will build on Win32
with native tools rather than a posix shell emulator)

Hi James,

I actually agree to Etienne's proposal: that is, calling directly the Windows' threads APIs.

Enrico

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Re: [sablevm-jchevm] Windows port

Hi folks, Hi Enrico, Enrico Migliore wrote: Let's see if I get your suggestion right: 1. Use the "thin abstraction layer atop already-provided operating system support" http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Thread.html Yes, exactly. :-) At first sight, it seems to provide all the functionality that SableVM needs. 2. Use #if defined (WIN32) to separate WIN32 from Linux code Yes, for the now. Points 1 and 2 requires me to study some Windows' thread APIs. I would prefer to actually get any such code either: 1- out of SableVM, e.g. into a separate library or in Harmony's port layer, and/or I'm figuring the folder layout structure, to put somewhere, please let me know if you find it reasonable: win32 |_____src (proposal A) |_____include arch |_____win32 |______src (proposal B) |______include those are just 2 proposals that came to my mind during the weekend, but I'm open to any options. 2- into well defined system-specific files in SableVM's source code. For this initial part of the port, I can make a local copy of the files that require Windows specific functions, in the folder: "src" and "include", and work on them. As said, before starting the port, I will read over all the threads we wrote, read the documentation of SableVM, and make a written proposal to the list, in order to have the maximum level of agreement. I already did a quite complex port in the past (FreeDOS's filesystem ported to some embedded platforms) and it took me 6 months, to make a clean and reliable work. Enrico

Next Message by Date: click to view message preview

Re: [sablevm-jchevm] Windows port

Hi, I'm browsing the libffi source code and, at first glance, it seems that X86_WIN32 is supported. The file: win32.S , though, contains assembly code for x86 that looks a GCC friend but an MSVC enemy :-) movl %esp,%eax ciao, Enrico

Previous Message by Thread: click to view message preview

RE: [sablevm-jchevm] Windows port

>In any case, I think that the Windows port should rely on >the pthread library written for Windows. I don't think that's a very good idea: 1) it has the wrong license (I think - has pthread-Win32 changed?) 2) it uses the relatively high-level Win32 facilities to bodge together an emulation of rather lower-level facilities. If you then use that to implement a higher-level abstraction again for Java with recursive locks and signals, then its likely to be less than optimal. Better, then, to look at a focussed abstraction and implement for both threading models as efficiently as you can. Bear in mind that the Win32 threading has the weight of a rather large number of host systems behind it. You might be better off with ZThreads if you really don't want to do a direct port - or (better) look at the high-level implementations you want, and offer them to APR (or APRUtil) based on the low-level code in APR. James (Also - it would be *really* handy to have a source tree thats more or less self-contained and will build on Win32 with native tools rather than a posix shell emulator)

Next Message by Thread: click to view message preview

Loading Comments...