Hi Marcel,
Thanks for you answer...
> the problem seems similar or the same to what Nick posted a view weeks
> ago. If you use blocking connect() in one thread the close() in another
> thread will not terminate the connection attempt. As far as I can tell
> this is true and should be fixed. It however works fine if you just
> would use proper non-blocking connect() with a mainloop.
The problem of this method is the control of errors. The call to connect
function is blocking (because we need to
know if the user of the terminal can not connect errno==ECONNREFUSED).
If the connect is not blocking .... i don?t know how evaluate a possible
error. The errno haven?t the error...
(we need to know if the user rejects the connection: In the case of Obex...
the send of the file)
Any Idea?
Thanks in avanced.
Best Regards,
Abraham.
Abraham J. Velez (EndoraSoft) wrote:
>> the problem seems similar or the same to what Nick posted a view weeks
>> ago. If you use blocking connect() in one thread the close() in another
>> thread will not terminate the connection attempt. As far as I can tell
>> this is true and should be fixed. It however works fine if you just
>> would use proper non-blocking connect() with a mainloop.
>
> The problem of this method is the control of errors. The call to connect
> function is blocking (because we need to
> know if the user of the terminal can not connect errno==ECONNREFUSED).
Does this not work? From connect(2):
EINPROGRESS
The socket is non-blocking and the connection cannot
be com-
pleted immediately. It is possible to select(2) or
poll(2) for
completion by selecting the socket for writing. After
select(2)
indicates writability, use getsockopt(2) to read the
SO_ERROR
option at level SOL_SOCKET to determine whether
connect() com-
pleted successfully (SO_ERROR is zero) or
unsuccessfully
(SO_ERROR is one of the usual error codes listed here,
explain-
ing the reason for the failure).