On Mon, Apr 24, 2017 at 9:00 AM, Carsten Haitzler <[email protected]> wrote: > On Mon, 24 Apr 2017 05:46:17 +0200 Vincent Torri <[email protected]> > said: > >> On Mon, Apr 24, 2017 at 4:57 AM, Carsten Haitzler <[email protected]> >> wrote: >> > On Wed, 19 Apr 2017 09:42:50 -0700 Cedric BAIL <[email protected]> said: >> > >> >> On Tue, Apr 18, 2017 at 11:02 PM, Jean-Philippe André <[email protected]> >> >> wrote: >> >> > On 19 April 2017 at 14:53, Vincent Torri <[email protected]> >> >> > wrote: >> >> >> now that evas depends on ecore, should cserve2 be ported to ecore ? >> >> > >> >> > If anyone wants to do it, why not. >> >> >> >> I guess it would simplify the code. >> >> >> >> > cserve2 isn't used because it still has issues, especially after one >> >> > side >> >> > crashes (server crash in particular). >> >> > Also the performance results were rather worse than local-only image >> >> > loads, while the original premise of cserve was to improve the perfs. >> >> >> >> As a tradeof, it did help for memory use... when everyone was using >> >> the same theme. There is still potential for improvement, but a lot of >> >> more additional work is actually necessary and depending on your use >> >> case, it may or may not help. >> > >> > actually the absolute nicest thing about cserve was that loading was farmed >> > off to slave processes. this meant any crashes in a loader at most took >> > down some slave process. >> > >> > the whole image loading subsystem though needs a rewrite/redesign. we can >> > use actual loader code we have, but all the stuff above it needs a re-do. >> > >> > my thoughts are that we should really externalize the loaders via some >> > slave >> > process. now to do this portably and keep performance high is the trick. >> > >> > on unix i'd simply vote for allocating shared memory segments in the slave, >> > then fd passing them back to the parent via a socketpair. in fact just >> > using >> > memfd if possible. this is not so easy for windows. well i don't know if >> > it's even possible. >> > >> > also any rewrite would totally move all the loader core code to a slave >> > thread with anyone requesting work from it to do it via "ipc" to that >> > thread. >> > >> > does anyone have any insight on windows here?can we write some portability >> > wrappers maybe in eina/ecore to make this easier? >> >> On Windows, you can create the equivalent of anonymous shared mem: >> 1) To create shared mem, see >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa366537 >> (v=vs.85).aspx , with INVALID_HANDLE_VALUE as first parameter. >> 2) To access to an already created shared mem, see >> https://msdn.microsoft.com/fr-fr/library/windows/desktop/aa366791 >> (v=vs.85).aspx >> >> Example: https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551 >> (v=vs.85).aspx >> >> I've already used that so that 2 processes can comunicate, so some kind of >> IPC >> >> Eina_File_Open already does 1), so we can maybe add an API in Eina for 2) > > so reading this - they dont PASS it from process A to B, but agree on a name > (like sysv shm with a shmid or posix shm with a name for shm_open). can you > PASS a handle - the handle itself, from one process to another?
yes, like shm_open to share any kind of data, I create a shared mem of size type + data. > my thoughts here are to have some of these basics hidden in eina + ecore > (ecore_exe specicially). that would help Vincent ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
