commit d37c22be20c83cf370638a9bad243bc5219c5509

[Marcel Holtmann]

Hi Giacinto,

was it necessary to remove entirely the NEED_THREADS flag?
I was going to use it in the Gemalto driver, to speed up the device recognition, because for some modules it is hit and miss.
But only as an optional feature, because in some systems it might be missing.
Also, for some high-speed modems which take long to boot, there is a potential critical race in the recognition that the use threads can solve easily. The alternative is to increase the internal timers a lot.
I likely need to add a new flag for it.

using threads is not the solution. This can be all done properly with single thread event loop driven methods.

Regards

Marcel

[Marcel Holtmann]

Hi Giacinto,

Post by Marcel Holtmann

was it necessary to remove entirely the NEED_THREADS flag?
I was going to use it in the Gemalto driver, to speed up the device recognition, because for some modules it is hit and miss.
But only as an optional feature, because in some systems it might be missing.
Also, for some high-speed modems which take long to boot, there is a potential critical race in the recognition that the use threads can solve easily. The alternative is to increase the internal timers a lot.
I likely need to add a new flag for it.

using threads is not the solution. This can be all done properly with single thread event loop driven methods.
for sure, and in fact as of now the support is optional.
But I already need to ask for an extension of the Powered timout from 20 to 60 seconds because several LTE chipsets take at least 30-40 seconds to boot once they have already enumerated on USB. It would be good to shorten this time.
Besides, several modules use the option linux driver, which blocks in case the port doesn't answer.
g_at_chat_unref(port);
blocks either 30s or 1 minute, depending on the system. I might step into it twice during my hardware initialization for several 3G models.
It helps to run this line on a separate thread unblocking the rest.

no it does not. Nothing in GAtChat is thread safe. So running this in a separate thread just means you are having tons of race conditions on your hand.

Regards

Marcel

[Denis Kenzior]

Hi Giacinto,

Post by Marcel Holtmann
Besides, several modules use the option linux driver, which blocks in
case the port doesn't answer.
g_at_chat_unref(port);
blocks either 30s or 1 minute, depending on the system. I might step
into it twice during my hardware initialization for several 3G models.
It helps to run this line on a separate thread unblocking the rest.

What system call blocks (use strace to determine this) ? If anything
inside the option driver blocks for 30-60 seconds, that is unacceptable
and needs to be fixed in the kernel.

Regards,
-Denis

[Denis Kenzior]

Hi Giacinto,

Hi Denis,

Post by Marcel Holtmann
Hi Giacinto,

Post by Marcel Holtmann
Besides, several modules use the option linux driver, which blocks in
case the port doesn't answer.
g_at_chat_unref(port);
blocks either 30s or 1 minute, depending on the system. I might step
into it twice during my hardware initialization for several 3G models.
It helps to run this line on a separate thread unblocking the rest.

What system call blocks (use strace to determine this) ? If anything
inside the option driver blocks for 30-60 seconds, that is unacceptable
and needs to be fixed in the kernel.

I have finally had time to come back to this.
It is the close(fd), called in the g_lib that blocks.
I have further discovered that it is due to the fact that there are
write pending, and in this case a the closing_wait timeout kicks in.
I tried to remove this timeout with an udev rule, but it doesn't work.
I could set - still through udev, a call to the tool setserial, but it
doesn't seem proper, rules with scripts are heavy, and may also lead
to a wrong enumeration in udevng because some devices of the USB
enumeration are made available only after the rule has been executed.

I will study this a bit more. I'm surprised close can block a
O_NONBLOCK fd...

#include <asm/ioctls.h>
#include <linux/serial.h>
int ioctl(int, int, void *);
static void closeport(gpointer user_data)
{
GAtChat *port = user_data;
GIOChannel *channel = g_at_chat_get_channel(port);
int fd = g_io_channel_unix_get_fd(channel);
struct serial_struct old, new;
g_at_chat_cancel_all(port);
g_at_chat_unregister_all(port);
ioctl(fd, TIOCGSERIAL, &old);
new = old;
new.closing_wait = ASYNC_CLOSING_WAIT_NONE;
ioctl(fd, TIOCSSERIAL, &new);
g_at_chat_unref(port);
}
do you see a better way to do it?

Can we simply add this setting to g_at_tty_open?

Regards,
-Denis