(Apologies for the very late response, I'm way behind on my 'must respond' list)...
Marina Goldburt wrote: > Hi, > > As I see the main idea of the port library is " isolates all platform > specific knowledge to one area", as written at > "http://svn.apache.org/viewvc > /incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html > ". > > However, I've noticed that the code for sig, thread and luni modules also > contain the platform-dependent code. > For example, Java_org_apache_harmony_luni_platform_OSFileSystem_unlockImpl > function contains: > rc = UnlockFileEx ((HANDLE) handle, (DWORD) 0, > nNumberOfBytesToUnlockLow, > nNumberOfBytesToUnlockHigh, (LPOVERLAPPED) & overlapped); > Where the handle was produced by hyfile_open function. It will lead to > problems when somebody tries to replace the portlib with a > different implementation, that can use not os-handles. > > Will it make sense to extend the portlib functionality and move such > platform-dependent code from sig, thread, luni modules to the portlib? And the short answer is "yes". The additional file system functionality such as file locking and memory mapping required by the (newly authored within this project) NIO code should be put into the port library. Paulex: is this this something you are considering? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
