On Tue, 9 Jan 2018 08:31:36 +0100 Stefan Schmidt <ste...@osg.samsung.com> said:
> Hello. > > > On 01/09/2018 07:50 AM, Carsten Haitzler wrote: > > On Mon, 8 Jan 2018 09:38:38 +0100 Stefan Schmidt <ste...@osg.samsung.com> > > said: > > > > i wish i has an osx vm to test in... i did test windows, freebsd builds as > > well as linux. > > Yeah, its a pain to work with. Marcel asked for the same for his meson work. > >From what I understand you need to run such a vm also on Apple hardware by > >license. > (Makes one wonder why we care about support for them when they do not for > supporting developers) > > Does your freebsd runs fine for the build edje_cc as well? It could be the > closest you have to osx. yup. it all built perfectly on freebsd as well as linux. > Sadly all I can offer here is the Travis build which does not allow shell > access as far as I know. What Marcel did was getting ssh access to a osx > machine from netstar to do its testing. that's a major pain. i really don't know what should cause this. the only change is to put all signal traps into a pipe and have the pipe handler then handle it. i checked things like counted # of reads and writes of signals and always saw the read and write numbers ended up matching (which is what it should do) on both freebsd and linux. fyi this change actually fixes a race condition where we might lose some signals (and we've been lucky not to really see it). :( > > where is the break? i do see: > > > > Ecore sig handler NOT called from sigwatcher thread > > > > this is kind of an "error marker" where signal handlers are being called on > > other threads. only on windows is the sigmask stuff disabled. the signals > > are masked out on all threads EXCEPT the sigwatcher thread... technically > > this isn't really necessary given the way i did things with pipes... i can > > probably even remove the watcher and just have signals called anywhere as > > write()'s to the pipe should be atomic/mt/signal safe (for the small amount > > of data that is written). > > > > but where is the build break? i see no error. oh wait. need to look at the > > raw log. > > > > edje_cc: Critical. Unable to open temp file "(null)" for script compilation. > > > > No output has been received in the last 10m0s, this potentially indicates a > > stalled build or something wrong with the build itself. Check the details on > > how to adjust your build configuration on: > > https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received > > > > that? edje_cc is hanging? > > Yes, this build error was not a compilation break but our own build edje_cc > not working when being used later in the build. > > > why? the changes still use signal handlers and every > > signal is write()n down a pipe that the main loop reads and thus handles as > > events... ? unless a write() went missing ... which i doubt, or a signal > > handler wasn't called for a sigchld... but the signal handlers are not > > enabled/disabled or blocked/unblocked as things run... as i said - can > > remove the thread but i doubt that makes any difference. it shouldn't. > > To be honest I have no clue about the different behaviors of thread handling > in osx. > > I will try a revert of your patches in a branch to get Travis building them > (Travis and thus osx builds are now being done for all branches not only > master. It only gets triggered after the github sync each full hour, though). > > That should at least give us an idea if latest master works again with them > reverted. Not really debugged, but at least verified that it is one of these > patches and not something else. well debugging is needed, and a real osx machine with cmdline would be necessary for that. :( but as i mentioned .. i can't see why it'd have this issue. literally the signal mask is set ... but its somehow being called from a thread other than sigwatcher. finding out what thread they are being called from might be a first step to knowing what is going on. but as i said.. even if it were not it should still work thanks to write() to the pipe being mt/atomic safe etc. > regards > Stefan Schmidt > > ------------------------------------------------------------------------------ > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
