On Mon, 24 Apr 2017 09:53:55 +0200 Vincent Torri <[email protected]> said:
> 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. ok. but it's not possible to send a handle over some ipc socket - right? like on unixen (where you don't need to create some publicly addressable-by-name segment). another question. can you pass file handles from one process to another? or it has to be filenames only. actually i think this should really all just be abstracted by ecore_exe+ecore. don't need to put it in eina. > > 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 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
