
25 Nov
2004
25 Nov
'04
3:54 a.m.
"Ion GaztaƱaga" wrote: > do you know any windows implementation > for process-shared condition variables? Maybe http://www.garret.ru/~knizhnik/shmem/Readme.htm > I would love also non-connection oriented message oriented ipc, > something similar to datagram unix socket or a connection oriented stream > ipc, like stream unix sockets. As far as I know cygwin a similar uses > TCP/IP > to emulate unix sockets, so I have not seen a pure windows source code > anywhere. > Giallo library (http://giallo.sf.net/ typed from head) is attempt to create TCP/IP Boost library. It may or may not fit with this request. [exceptions versus error code] > When using create only version, if the object is already created, I > suppose > you would like another exception to be thrown, something like > boost::shmem::already_created. The no throwing versions would return 0 if > any error is found. Is that right? > Copy constructor may throw. [lean offset_ptr] > A char pointer could point to any byte in the segment, so (ptrdiff_t -1) > would be valid. I can add a new base class for offset_ptr that considers > (ptrdiff_t-1) zero, so that the user can use that pointer if he wants. > I wanted to write (ptrdiff_t)-1 or 0xFFF...FFF. >12. The simple algorithm to find fitting memory >> Maybe if the library has interface to plug in different >> algorithm (no clue now how it would look like). > > I will add another algorith to show that algorithm can be chosen via > template parameter. > An inspiration for algorithms could be found on http://www.hoard.org/ (it is complete and complex framework with lot of allocators). [fixing buggy STLs vs own containers] >> Maybe the library could list those offending STLs and instruction how >> to fix them manually to be useable with shmem. Such a fix should >> not change behaviour of applications, right? > > I will add changes needed for Dinkum STL, but I don't know if publishing > template lines and the changes needed can lead to any legal problem. > Problems: would be ridiculous IMHO. People may not like to fiddle with STL but it could be stressed these changes are safe. >>>>d) support for "transactions": I would like to >> - transactions with isolation level 1: >> - transactions with isolation level 2: > > Sounds like it can be a layer above shmem library, another library > perhaps. > I am not sure: - transaction mechanism would likely need to have access to very details of shmem on low level (like checking whether an object is still there not via exception). I have feeling shmem should be designed and tested with hooks to support transaction. Ideally there would be common framework for transactions libraries like shmem would implement and obey. /Pavel