| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Checking call_out only and stopping the call as soon as call_out
is gone is not desirable behaviour.
It now keeps up the running call until both call_out and call_in
have been "closed", no matter how or by whom it was started.
This is done by introducing av.state, which is a bit field.
While at it, I also incorporated the transmission-state into it.
toxav_hangup() will now only be called from the one centralized
flag-checking-loop before select, not in the callbacks themselves.
This will also get rid of some race-conditions (more or less).
Previously, call_out was constantly polled as long as the user
was online. Change this to only attempt to open call_out when the
call is initialized. This lowers CPU-usage dramatically.
|
|
Oops kfreebsd builds break. Aw well.
|
|
AV-logging, logic and check for < 0 instead of == -1 (just to make
sure).
|
|
This change halves CPU usage on my system.
|
|
|
|
toxav_prepare_transmission() sets the internal toxav `call_active'
state variable. This is checked in toxav_kill_transmission() and
only if set, proceeds to release the resources.
|
|
Do this in two ways:
1) only allow ratox to stay in the file-sender for a certain amount
of time
2) Stop hammering tox_file_send_data(). When it returns -1, we put
the given friend into a cooldown-state, because all internal transmission
slots are full.
File sending thus now works in bursts, reading from file_in as long
as tox_do() allows or until tox_file_send_data() fails.
An easy way to see why we need to do the former is piping /dev/urandom
to file_in, which never blocks. Effectively, the user goes "offline"
after a while given he is trapped inside the loop.
Piping to /dev/urandom is not an unrealistic testcase. Imagine a
researcher who desperately needs true random data from his special
RNG in his lab using ratox and piping it through /dev/urandom.
|
|
rename file_pending to file_state
rename call_pending to call_state
0 = no call
1 = call pending
2 = call active
|
|
Due to a bug in toxcore the call is set to active too early,
leaving room for invocations of sendfriendcalldata() even though
the transmission has not yet been set up in cbcallstart.
Fix this with a small workaround keeping the transmission-state
in the client.
In the long run, this definitely needs to be fixed in toxcore
for consistency.
|
|
Basically the direct calls to cancelcall() should be minimized
and only set off in a callback.
Additionally, tweak other error-cases and don't always quit fatally
but instead provide ways to get out of an error-condition.
|
|
Now it's fun again to work with the code.
|
|
using the udata-void pointers to pass data as a source of information.
|
|
This saves a lot of LOC and is definitely easier to maintain.
|
|
|
|
|
|
|
|
In upcoming commits, these errors will be incorporated into the
logging-system, so they don't look so out of place when issued.
|
|
|
|
When you got a request, but not accepted it via request/out/... and
instead sent a request yourself, it would not remove the FIFO.
This patch fixes this behaviour by iterating through the request-
list and removing the FIFO if it's still existing.
Additionally, actually make it possible to reject requests and
re-add your friends later by managing the internal tox-state
properly.
|
|
Similar style as for detecting broken file transfers.
|
|
if (f->rxstate == TRANSFER_INPROGRESS &&
(fd = openat(f->dirfd, ffiles[FFILE_OUT].name, ffiles[FFILE_OUT].flags, 0666)) == -1 &&
errno == ENXIO) {
...
} else {
close(fd); <--- not always appropriate!
}
|
|
This will trigger the callback and reset toxav internal states
accordingly. In the callback we actually call cancelcall().
|
|
|
|
If not, abort receiving.
|
|
|
|
|
|
No need to try to keep local state, just use toxav_get_call_state().
We now can auto-accept calls by pre-attaching on the call_out FIFO.
|
|
|
|
|
|
Reject calls on both sides to reset states. This still needs
to be tested to see if there's any effect of doing that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I don't know why I missed that
1) of course we have to check tv_sec, not tv_nsec
2) when we do a nanosleep, but use the "now"-val for the lastsent-
time, we obviously keep the wrong time.
This leads to the program thinking more time elapsed than really
has, leading to less nanosleep and thus higher playback-speed.
Now this is fixed, and apart from state-transition issues,
call-receiving now works perfectly. ;)
|
