Opened 15 years ago
Closed 15 years ago
#11 closed task (fixed)
Port HPI
Reported by: | dmik | Owned by: | |
---|---|---|---|
Priority: | blocker | Milestone: | Core |
Component: | general | Version: | |
Severity: | Keywords: | ||
Cc: |
Description
HPI (I believe) stands for Hardware Platform Interface and in case of JDK this encapsulates platform-specific memory management, threading and other basic things and exposes it the platform-neutral way.
Change History (2)
comment:1 by , 15 years ago
Milestone: | Alpha → Core |
---|---|
Priority: | major → blocker |
comment:2 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
Finished porting HPI. Some remarks:
Note that the fact that we are using kLIBC may be a potential problem because in the real Windows world there is a certain amount of correlation between the usual C runtime (MSVCRT) and Win32 API. For example, the C file descriptor may be turned into a Win32 file HANDLE while the kLIBC file descriptor (which is in fact a raw HFILE value except for the socket file descriptors) may not. Another problem is that we have to start/stop threads with Win32's CreateThread()/ExitThread() instead of _beginthread()/_endthread() thus bypassing kLIBC thread initialization and termination which may have various side effects. We will see later how dangerous all this is.
There is actually no real alternative to kLIBC ATM -- the provided
MSVCRT port is not complete. If things go wrong we will probably have to hack into kLIBC as an option.