It's entirely possible that a system doesn't have a cpu 0, so
when we try to pin all our render threads onto processor 0 we
may fail.
This results in some very connfusing build breakage when
edje_cc hangs up because its render thread didn't start.
So, if starting the thread with affinity fails, let's try without
affinity.
(This is trivial to reproduce - just use sysfs to turn off cpu0
after boot.)
@fix
This fixes argb windows transparency in E software compositor.
My current problem is that I have no idea what changed, why this
is needed now, and how things could actually work before.
Fixes T4389
@fix
so ok - efreet crashed letting you know you have a missing mimedb...
return NULL instead fixes T4425 :) - rememebr to kill your efreetd's
to get a new mimedb - log out and in will do that.
The use of low-level interfaces such as Efl.Io.Reader and
Efl.Io.Writer are not that user-friendly as they can handle partial
data.
Classes such as Efl.Io.Copier makes them easy to use, but they need a
reader (source) or writer (destination) and in our examples we used
fixed buffers or some existing streams (stdin/stdout/stderr,
networking...).
However, if interactively we need to produce some data to be sent,
such as implementing some networking protocols, we'd have to write our
own Efl.Io.Reader and Efl.Io.Writer classes to handle the buffering.
Not anymore! With Efl.Io.Queue you can write stuff to it and it will
buffer to memory. Once stuff is read, it will automatically remove
those bytes from buffer.
We set the wayland surface to NULL in engine info, then destroy the wayland
surface later. The GL stack tries to render to the destroyed surface and
dies.
If we destroy the GL surface when we set the engine info (before we destroy
the wayland surface)it stops the GL stack from doing bad wayland calls.
This fixes a crash on exit, or when any window closes when using mali GL
drivers. Surprisingly, Mesa was tolerant of this.
So actually there is quite a big issue with semaphores
on OSX. We use (named) POSIX semaphores, but this was
a (my) mistake... I'll fix it later...
The real issue is that named semaphore are persistants:
when the program dies, it stays alive. This is pretty
bad with eina_debug_monitor because we create a semaphore
we never release, due to a wild thread...
This leak of semaphores went unnoticed before commit
4a40ff95de because the
name of the semaphore was unique per process, and
overriden when another process was launched. This
was very bad, but saved us from overflowing the
semaphore pool. It is now overflowed pretty fast when
building a lot EFL, because of Eolian that runs A LOT!
So that's one problem that still needs to be fixed,
by using OSX' own semaphores (see T4423).
Another big issue, which is now fixed is that the
buffer in which we generated the semaphore ID was
too small, and therefore we were reduced to one shared
semaphore for a whole process... This buffer has been
now set to 31 characters, which seems to be the maximum
length of a semaphore ID.
So now things are better, but still with a deadly issue.
TCP_CORK is Linux only. TCP_NOPUSH is supposed to
do the same thing than TCP_CORK, but on BSD (including
Mac OS X).
We now check for the existance of TCP_CORK or TCP_NOPUSH,
and use the right option. If none exist, cork_{set,get}
will just fail.
This was never used and will probably never be used. It was just wasting
memory and making things more complicated.
Just to give some more concrete numbers, this change alone reduced the
number of dirty pages used by elementary by two. So quite significant.
BREAKS ABI
@feature
This was never used and there is no plan to ever use it. I'm going to
soon add a different mechanism with which it will be possible to provide
them again to Eo if ever needed without breaking ABI. Though it's
unlikely it will ever be.
As pointed out in the mailing list, it was introduced in this release,
so it's better to remove the symbol instead of deprecating it.
People should use ETIMEDOUT directly.
so efreet mime was loading a bunch of mime type info files, parsing
them on startup and allocating memory to store all this mime info -
globs, mimetype strings and more. all a big waste of memory as its
allocated on the heap per process where its the SAME data files loaded
every time.
so make an efreet mime cache file and a tool to create it from mime
files. mmap this file with all the hashes/strings in it so all that
data is mmaped once in memory and shared between all processes and it
is only paged in on demand - as actually read/needed so if your
process doesnt need to know about mime stuff.. it wont touch it anyway.
this saves about 240-300k or so of memory in my tests. this has not
covered the mime MAGIC files which still consume memory and are on the
heap. this is more complex so it will take more time to come up with a
nice file format for the data that is nicely mmaped etc.
@optimize
This class implements the Efl.Net.Dialer interface using libcurl to
perform HTTP requests. That means it's an Efl.Net.Dialer,
Efl.Net.Socket, Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus
being usable with Efl.Io.Copier as demonstrated in the
efl_io_copier_example.c
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.